https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106040
pj at patrickjohnston dot org changed:
What|Removed |Added
CC||pj at patrickjohnston
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92057
--- Comment #12 from pj at patrickjohnston dot org ---
Intentions aside, the concrete change given at the bottom of the paper doesn't
seem to reflect the non-narrowing conversion constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92057
--- Comment #9 from pj at patrickjohnston dot org ---
I'm sorry to belabour this, but I don't see how narrowing conversions even has
anything to do with p0608.
The only modification described by the paper (relevant to this ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92057
--- Comment #7 from pj at patrickjohnston dot org ---
Yeah but the `variant{600}` doesn't fail to compile due to this
narrowing conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92057
--- Comment #5 from pj at patrickjohnston dot org ---
So then why does `std::variant{600}` work just fine? (Where `Double` is
defined by `struct Double { double x; Double(int){} };`)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92057
--- Comment #2 from pj at patrickjohnston dot org ---
Initialising a `variant` from an `int` should not be an error due to
p0608. Compared to before, p0608 only requires that `double x[] = {600};` is
well formed. See https://wandbox.org/permlink
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at patrickjohnston dot org
Target Milestone: ---
Minimal testcase: https://wandbox.org/permlink/hzzjBrpCVZ4Cvwf8 (includes
output of gcc -v).
The problem did not exist in v9.2.0
