Re: [Boost-users] [boost] upcoming Switch library review Jan 5th - Jan 9th

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-01-06 23:03:43

Tobias Schwinger wrote:
> Stjepan Rajko wrote:

>>> o there is no way to determine this type with 'result_of.
>>>
> 
> Actually, the latter is more severe...
> 
>> The current implementation seems to use result_type - is it planned to
>> change to use result_of?
>>
>> I agree that result_of<F()>::type is slightly abusive, since that's
>> not what actually gets called.  
> 
>> Would using
>> result_of<F(boost::mpl::front<Cases>::type)> be an option for a
>> non-empty case sequence?  
> 
> I think it's too complicated: We can't use 'result_of' to determine the 
> result of 'switch_', so it should be as simple to determine as possible 
> (ideally without deduction at all).
> 
>> As long as the order of the cases doesn't
>> matter (btw, does it?), the user could put the desired type in the
>> front of the Cases sequence if the return type differs for different
>> MPLConstant types.
> 
> Further, we still need a special-engineered function object; one of the
> cases will have a special role. It might work, but it feels inelegant to 
> me: The function object's result type should be convertible to whatever 
> 'switch_' wants to return.
> 
> So what will deducing that type from the function object buy us?
> 
> The only answer I can currently see is "nothing but trouble" :-). Please 
> tell me if I'm missing something.

I haven't been following the review (yet, though I'll be in the next
few days) and I haven't read the docs yet. But from intuition, having
implemented at least 2 switch implementations (spirit and phoenix),
I'm guessing that there are N functions with N return types, right?
If so, it follows (to my mind) that the result should be a boost::variant
of all the possible return types given the arguments (through
application of result_of to all the functions).

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