Subject: Re: [boost] [result_of] now uses decltype on release branch
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2012-09-06 22:05:02
On Sep 6, 2012, at 8:39 PM, Joel de Guzman wrote:
> On 9/7/2012 3:37 AM, Eric Niebler wrote:
>> On 9/4/2012 8:01 PM, Joel de Guzman wrote:
>>> The question is: should we allow SFINAE for result_of. I think now
>>> that we should.
>> I made a case for this on the committee reflectors. They generally
>> seem to like the idea. In short: you were right, Joel. I'm now
>> generally in favor of changing result_of. Boost result_of can be
>> existing practice for (hopefully) a future change in the standard.
>> Daniel, is this something you're also interested in? I can see about a
Well, I'm not sure what you have in mind, but I went ahead and fleshed out my approach from the other night. I opened a ticket (#7343) and attached a patch. It seems to work pretty well, and the test suite passes. I also added a SFINAE test derived from Joel's example to the test suite. Let me know what you think.
As far as the standard, to allow a SFINAE compatible result_of implementation such as the one in my patch you would need language such as the following:
If the expression decltype(INVOKE(declval<Fn>(), declval<ArgTypes>()...)) is well formed, then the member typedef type shall name the type decltype(INVOKE(declval<Fn>(), declval<ArgTypes>()...)). Otherwise, if the expression decltype(INVOKE(declval<Fn>(), declval<ArgTypes>()...)) is not well formed, the expression result_of<Fn(ArgTypes...)>::type shall not be well formed.
Actually, I'm not sure if the term "well formed" is the right one here, but you get the idea.
>> Joel, since this is essentially your idea, would you be interested in
>> co-authoring a paper for the committee? I don't anticipate it would
>> have to be very long or elaborate.
> It'll be an honor to co-author a paper with you.
>> Also, apologies for my defensiveness earlier.
> No need for apologies. I just wanted to say that we need to keep
> a jovial spirit here in boost. We are all volunteers. We all
> make mistakes. Apologies for the xkcd-ish comment.
No need to apologies for xkcd-ish comments. xkcd is brilliant and the world would be a better place if we could all show such good humor and warmth. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk