[Bug libstdc++/113060] std::variant converting constructor/assignment is non-conforming after P2280?

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe D'Angelo from comment #0)
> GCC 14 implements P2280 (see #106650). 

N.B. if you say "Bug 106650" or "PR 106650" or "bug #106650" or pretty much
anything except just #106650 then bugzilla makes it a clickable link :)

> it seems that variant<float> should indeed accept construction from IC.

I'm not convinced that this change to the semantics of std::variant was an
intended side effect of https://wg21.link/P2280 -- I think I'd prefer if the
committee confirmed it.

The standard doesn't say that it _should_ work in a constant expression, it
seems like you're assuming that because it's now possible to implement it so
that it works, that it's required to work.

My reading of [variant.ctor] p14 is that "some invented variable x" is not a
constant expression, so using std::declval as a stand-in for "some invented
variable" is fine.

If we made this change, then some cases that compile today would become
ill-formed, e.g. see PR 113007. Under your reading, conversion from the
constant 42 would be valid for both int64_t and double, and so the
initialization would be ill-formed. But it would be well-formed when using a
non-constant int equal to 42.

Apart from the fact it would be a breaking change, the difference in behaviour
between runtime and compile time would be surprising. It would also mean that
std::is_constructible would be misleading: it would say you can construct
variant<long, double> from 42, but when you try to do that it would fail to
compile.