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

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.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net