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.
