Re: [boost] [result_of] Allow result_of to work with C++11 lambdas

Subject: Re: [boost] [result_of] Allow result_of to work with C++11 lambdas
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2013-04-21 10:48:13

On Apr 21, 2013, at 3:04 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> Le 20/04/13 23:25, Nathan Crookston a écrit :
>> Hi Daniel,
>> 
>> Daniel Walker wrote:
>> 
>>> Nathan Crookston wrote:
>>>> I just wanted to ping on this; see if someone's had time to review the
>>>> patch.  I failed to mention that the same parts of the full test suite
>>>> passes on VC10 before and after the patch, so there's some assurance that
>>>> it's correct.
>>> OK, I finally had a chance to look at the patch. The implementation is
>>> fine, but the configuration, documentation and tests allow/imply that
>>> BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK is enabled by default on
>>> certain compilers. I believe we should not stealthily change the default
>>> behavior. It seems to me that the migration path we adopted years ago
>>> should remain in place: the default behavior of boost:result_of will only
>>> change if your compile supports N3276, in which case you will get the full
>>> decltype implementation.
>>> 
>>> I think it would be best to introduce this functionality as a third
>>> option; i.e. one that the user opts into by explicitly defining
>>> BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK. (That's a good name for the
>>> macro, BTW.) If you could update the patch, I'd be glad to apply it.
>>> 
>> Thanks for looking over the patch!  I'd be happy to make the change, if
>> that means getting the functionality into boost.  However, I think that the
>> decltype fallback should be enabled at least for those compilers which have
>> both a lacking decltype implementation and C++11 lambdas.  This doesn't
>> change the migration path, of course -- as N3276 is implemented in more
>> compilers, more compilers will use the straight (standards conforming)
>> decltype implementation.
>> 
>> I don't think there are typical situations where someone using lambda
>> functions would *not* want boost::result_of to work for it.  However, I'll
>> submit a patch updated as you request in a few days, unless I and/or others
>> can help change your mind. ;)
>> 
> Could, defining BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK by default on these compilers, result on a regression on these compilers?
> 
> If not it should be done as it allows to take care of more cases.
> 
> Do we know of some regression cases?

It's not a matter of regressions but user expectations. boost::result_of's documentation has said for a long time now that if decltype is not used then TR1 is. It doesn't seem like a good idea to me to introduce a new default scenario, a hybrid, which is a little hard to explain. Everything is easier if there is one switch between two standards for the default behavior, namely, support for N3276.

However, there will also be regressions, i.e. valid user code that will no longer compile if we change the default. An obvious one is user code that is conditioned on the current two modes. If we change the default to a new third mode, then such code will suddenly fail to compile in the default case. For example:

struct functor {
    template<class T>
    T operator()(T);
};

template<class T>
struct S {
#ifdef BOOST_RESULT_OF_USE_DECLTYPE
    typedef boost::result_of<functor(T)>::type type;
#endif

#ifdef BOOST_RESULT_OF_USE_TR1
    struct TR1functor {
        template <class> struct result;
        template<class F, class U>
        struct result<F(U)> {
            typedef T type;
        };

        template<class U>
        U operator()(U);
    };

    typedef typename boost::result_of<TR1functor(T)>::type type;
#endif
};

typedef S<int>::type type; // error if the default changes

There will be more subtle errors as well. The following will compile by default on compilers with insufficient decltype support, since TR1 is used by default, but it will fail if we change the default to the hybrid mode.

struct functor {
   int operator()();
};

BOOST_STATIC_ASSERT((
   boost::is_same<boost::result_of<functor()>::type, void>::value
));

This is due to a dark corner of TR1: the result and result_type members are consulted in non-nullary functors but nullary functors always generate void. (See the section on known difference between boost::result_of and TR1 in the documentation.)

- Daniel