id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
4072,[result_of] decltype-based implementation breaking valid code on msvc-10,Eric Niebler,Douglas Gregor,"I recently looked into some proto failures on msvc-10 and traced them back to the use of decltype in the implementation of boost::result_of. The program below demonstrates the problem:

{{{
    // Uncomment the next line to make the problem go away
    //#define BOOST_NO_DECLTYPE
    #include <boost/utility/result_of.hpp>

    template<class X, class Y> struct pair {};

    template<class Base>
    struct S;

    struct wrapper
    {
      template<class T>
      struct result;

      template<class This, typename That>
      struct result<This(That)>
      {
          typedef S<That> type;
      };

      template<typename That>
      typename result<wrapper(That)>::type
      operator()(That) const
      {
          return 0;
      }
    };

    template<class T>
    struct S
    {
        S(int = 0) {}
        typename boost::result_of<wrapper(pair<T, T>)>::type foo()
        {
          return 0;
        }
    };

    int main()
    {
      S<int> s;
    }
}}}

The use of decltype in result_of causes the compiler to recursively instantiate templates until it blows its stack. To make the problem go away, you must #define BOOST_NO_DECLTYPE.

I suspect the real problem is in a buggy implementation of decltype on msvc-10. For the upcoming boost release, I suggest that we stick with the non-decltype implementation of result_of on msvc-10, or risk massively breaking users' code, not to mention proto, spirit and xpressive on that compiler.
",Bugs,closed,Boost 1.43.0,utility,Boost Release Branch,Problem,fixed,decltype result_of msvc-10,daniel.j.walker@…