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. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net