Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-09-27 08:42:47
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).
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).
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)