...

gcc 4.8.1 and 4.9.0 will support N3276 decltype. ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 )

May I commit an attached patch?

Nice. It's John Maddock's call, but I would love to see this.

If it passes the tests, then sure go ahead and commit. John.

The implementation is complete. Unfortunately, my fixes for DRs 337 and 657 are interfering with the desired result; creating a function type returning an abstract class causes deduction to fail, so we instantiate the return type of wrap in order to determine whether it is abstract. I guess I'll disable

I reported to the PR ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 ) that the implementation of N3276 decltype was not complete, since the compilation of the following code exhausted all resources: template<class T> struct S; template<class X, class Y> struct pair {}; template<class T> S<T> wrap(T) { return 0; } template<class T> struct S { S(int = 0) {} decltype(wrap(pair<T,T>())) foo() { return 0; } // ERROR S<pair<T,T> > bar() { return 0; } // OK }; S<int> s; Jason Merrill responded that gcc's implementation was complete and the failure was due to the conflict with the fix for DR 337 and 657. **It seems that the Core Issue will be raised**: Jason Merrill: that

instantiation and raise this issue with Core...

And the fix has been committed: Jason Merrill:

The change to force instantiation to check for abstract return types broke this change; until the core SG has a chance to discuss the language inconsistency, I'm going to disable that instantiation in decltype context.

Tested x86_64-pc-linux-gnu, applying to trunk.

I confirmed the fix and the test ran fine. So I committed a Boost.Config fix in r83625: https://svn.boost.org/trac/boost/changeset/83625 Regards, Michel