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

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-01-07 05:17:01

Tobias Schwinger wrote:
> 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? 

Use the variant visitor. That may amount to the same thing, but
in this case, we have a value, not a function that returns a value.

> It might but isn't necessarily what we want.

Why not?

> 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.

Sorry, perhaps I missed the "extra metafunction" solution.
What is it again?

Anyway, you have good points. Yes, an explicitly specified return
type would be ok too. In the standpoint of optimization, yes, a
variant return is suboptimal at both compile time and at runtime.

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