Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-09-27 09:27:24
Mathias Gaunard wrote:
> Joel de Guzman wrote:
>> And, not to be forgotten, there's also the Lambda Phoenix
>> relationship. I personally would not want to have Phoenix2
>> as-is into Boost without providing a strategy for a painless
>> transition for old Lambda into the new. The review is a good
>> opportunity for all these matters to be discussed.
> I suppose adding support for the sig template in boost::result_of would
> surely be of use.
> I remember a technique to detect template members was discussed, so it
> ought to be possible.
> Also, when using decltype or emulation, there should be no problem,
> since the return type deduction technique isn't used at all.
> On a related note, I think compatibility with the result_type protocol
> is also very important, since it is still what the standard library
> uses. (I don't know if it's ever planned that it will use result_of
> instead, but for the moment my standard library -- latest GCC --
> requires result_type on its function objects fairly often).
AFAIR, the old standard library result_type protocol is compatible
with the result_of protocol.
> So as I said in another thread, phoenix should try to provide
> result_type whenever possible. A simple make_monorphic<T1, ..., Tn>(f)
> helper could also be useful (it would simply invocate result_of with the
> template arguments to generate the result_type).
Ok. Let's see how it goes. Good suggestion.
> Also, monomorphic function objects should be able to lead to even
> clearer error messages, so it could be interesting from that point of
> view too.
> Ideally, it would be nice if the signatures of the generated objects
> were as restricted as possible, in a similar way to inference in ML.
> (one could think of using SFINAE to check the arguments have all the
> necessary proprieties for the function call -- but I wouldn't require
> that of Phoenix)
These are all very good comments and suggestions.
-- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk