On 18/03/2011 01:35, Stephan T. Lavavej wrote:
[Eric Niebler]
Yes. So the behavior of vc10's decltype wrt this issue is in conformance with /current/ working paper -- which is broken, according to n3233. It will be discussed soon in Madrid. If the proposed wording is accepted (and I hope to god it is), then VC10's decltype --along with everybody else's-- will need to be fixed. But please fix it anyway. :-)
I'll ask the compiler team for a fix. I don't always get what I want, but the STL is the compiler's first and best customer, and I've been looking forward to making result_of 95% powered by decltype.
(Keeping track of rvalue references v2, lambdas v1.1, rvalue references v2.1, rvalue references v3 - I actually don't know if that one was reverted in the Working Paper - and now decltype v1.1 can be exhausting!)
MSVC also has a lot of bugs with function types in general, which can affect result_of, function, or other similar things negatively. Here is one bug: https://connect.microsoft.com/VisualStudio/feedback/details/282942/syntax-er... Here is a testcase of another bug that causes an error in result_of: void foo(int) {} struct bar_t { template<typename Sig> struct result; template<typename This, typename F> struct result<This(F)> { typedef void type; }; template<typename F> void operator()(const F&) const { } }; template<typename F> typename std::tr1::result_of<bar_t(const F&)>::type bar(const F& f) { bar_t b; return b(f); } void call_foo() { bar(foo); } This fails with an error message in _Remove_reference called by _Result_of. Changing it to bar(&foo) allows to work around the problem though.