Hi all. The primary purpose of decltype, according to the decltype/auto proposal, seems to be to assist in creation forwarding functions, something like: template<class F> decltype(F()()) forward(F f) { return f(); } For example, if f is declared to return const rvalue: const x f(); using the real decltype (in the future, of course) would result in: const x forward(const x(*)()) { return f(); } Which is, of course, what we expect in this case. Since LVALUE_TYPEOF has a problem distinguishing const x from const x&, using it in the above case would result in: const x& forward(const x(*)()) { ^^^^^^^ return f(); } Now, my question is: isn't this fine? The same rule (extending the lifetime of const reference) that prevented LVALUE_TYPEOF from working correctly, seems to now ensure that it is fine to use this "incorrect" result. Another example of (it seems) the same thing is the treatment of "volatile" by Microsoft compilers (both 7.1 and 8.0). It seems to be fine to write: volatile x vf(); volatile x& vr = vf(); provided x is a UDT, and has a copy-constructor accepting [const] volatile x&. (I don't know if this is a compiler bug, or the lifetime is also extended. I also don't know if this standard-compliant.) Needless to say, LVALUE_TYPEOF(vf()) yields volatile x& instead of expected volatile x (my local version, after adding the treatment for volatiles). If x is not a UDT, the above binding doesn't work, but LVALUE_TYPEOF(vf()), guided by the same exact mechanism, would also yield just x. Let's generalize a bit. When writing a forwarding function, shouldn't we, instead of asking: what is the exact return type of the wrapped function? just ask: what is the type to which the result of the wrapped function can be bound without loosing functionality [on this particular compiler]? It seems to me that using the simple mechanism of binding a reference yelds the results that are at least as good (for this particulat purpose, of course) as those that the real decltype could provide... But maybe I am missing something? Regards, Arkadiy