[result_of] decltype-based implementation breaking valid code on msvc-10

[Eric Niebler]

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.

[Eric Niebler]

patch for result_of on trunk

[Eric Niebler]

See ​here for the bug I filed against msvc-10 regarding its decltype behavior.

[viboes]

Closed as merged on release branch.