Re: [boost] [Review] Phoenix review starts today, September 21st

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)