http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Daniel Krügler from comment #3) > IMO it is important to fix at, because otherwise > it does have the potential to subtly change overload selection (if noexcept > is used as part of sfinae) and other static introspection tests. Your interpretation is probably right (I'll let other developers handle it anyway). Let me just say that I see this change in overload selection as a *good* thing, not something we have to fight against. Yes, it is subtle. But if the compiler knows it will elide the copy (assuming it is consistent between the noexcept detection and the actual code generation) and the copy is the only operation that may throw, not taking advantage of this information is a fairly gratuitous code pessimization. Copy elision changes the set of functions called, it can change the program's behavior in very visible ways, changing exception specification looks like a rather minor thing to me in this context. If people rely on exception specification that badly, they should probably specify them more explicitly (afaik that's the argument that was given against noexcept(auto)).
