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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-07 04:29:53

Joel de Guzman wrote:
> 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).

What are we going to do with that Variant? Switch again and go back 
where we're coming from? It might but isn't necessarily what we want.

Now in order to get our Variant we have to
o  check result_of<Fn(arg)>::type for every function,
o  figure out unique types, and
o  make a variant from them, possibly handling special cases like using 
Boost.Optional or the bare type where more appropriate.

It's surely useful for certain use cases but takes a lot of template 
instantiations, so I think it should be an extra metafunction.

Regards,
Tobias