http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000
Marc Glisse <marc.glisse at normalesup dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marc.glisse at normalesup
| |dot org
--- Comment #3 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-24
19:31:52 UTC ---
(In reply to comment #2)
> Confirmed.
>
> I suppose we could make the libstdc++ change now rather than waiting for the
> FE
> fix, as it shouldn't change the current behaviour of the library.
It doesn't seem completely obvious to me that this is the right library fix.
What happens if instead of the standard declval you use the trivial version?
template<typename _Tp> _Tp __declval2() noexcept;
(except for the obvious problem with indestructible types, but then the decay
version may give you an answer that isn't constructible from the input for
references to a non-copyable type, so that's fair)
Rereading the DR, it appears that some people actually want to decay
independently from this rvalue issue, which is quite a strong change. And after
all, people can use decay<common_type>, but if decay is included in
common_type, it can't be undone.
Although now that I think as a library writer who has to specialize common_type
for some of his types, I don't really want to specialize it for all cv-ref
variants of my types, so I'd actually like the default common_type to decay not
only the result, but also its arguments! And while we are at it, it could even
try canonicalizing them, like operator auto().
Hmm, I guess you can forget this rant and go ahead (I am still posting it
because there may be real arguments somewhere).
