http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49266
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> 2011-06-04
23:42:03 UTC ---
(In reply to comment #1)
> Thanks Marc. I guess we need a definitive word here about whether these are
> c++
> front issues or unavoidable problems caused by the implementation of the
> traits
> via sfinae.
This definitely is not a front end bug.
> In the latter case we have unfortunately to be prepared to revert
> all the noexcept work involving traits until we get front-end support. Very
> sad, of course: personally, I didn't think sfinae-based techniques had serious
> limitations besides access-control. Would be something worth popularizing, can
> affect a lot of sfinae uses outside the library too, of course.
I don't think this is a sfinae vs intrinsic traits issue; intrinsic traits
would do basically the same thing. It's an issue of involving traits/sfinae in
function signatures so that we trigger more instantiations when considering a
function during overload resolution rather than later, when the function is
instantiated. The idea about deferring instantiation of exception-specifiers
seems likely to address this for noexcept specifically, but there might be
similar issues caused by increased use of sfinae for selecting between
overloads.
*** This bug has been marked as a duplicate of bug 49107 ***
