Subject: Re: [boost] [result_of] now uses decltype on release branch
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2012-09-05 19:39:33
On Sep 5, 2012, at 6:56 PM, Joel de Guzman wrote:
> On 9/6/12 1:00 AM, Eric Niebler wrote:
>> On 9/5/2012 12:14 PM, Joel de Guzman wrote:
>>> On 9/5/12 11:33 PM, Eric Niebler wrote:
>>>>>> I'm not sure. To me, I think it's easier to simply avoid result_of
>>>>>> on C++11 and just use decltype directly. Problem solved. Why use an
>>>>>> inferior tool when something better is available anyway?
>>>> In the case where you need an overload to drop out because of the
>>>> ill-formed-ness of a call expression, I agree with you. If you mean to
>>>> swear off using result_of entirely because of this issue, then you'd be
>>>> making your code non-portable for no good reason.
>>> How so? I can keep using result_of in '03 code and use decltype
>>> in '11 code. I see no reason how that will be non-portable.
>> I mean that you can use boost::result_of everywhere except where you
>> need to select overloads on
> So avoiding result_of == non-portable ?
result_of buys you some portability in so far as it can work in C++03 whereas decltype is purely a creature of C++11. result_of is also convenient for the common case where you just want to use perfect forwarding; e.g. it's less tedious and more readable than writing long strings of declvals wrapping your arguments inside the decltype.
>>> PS> If you stop acting like the police, perhaps more people
>>> will stop behaving like renegades ;-)
>> The winky-face here doesn't make that comment acceptable. Since when is
>> maintaining a library "acting like the police"? Let me remind you: we're
>> here because you've been neglecting the maintenance of your own
>> libraries, Phoenix and Fusion, which have been broken by the
>> decltype-result_of on trunk since APRIL.
> That tone is exactly my point ;-) And yes, that's another winky face.
I feel like the thread is degenerating into an xkcd cartoon... which isn't necessarily a bad thing. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk