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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-07 07:14:38

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

Because we're just coming from inside the switch and if we wanted to do 
something conditionally we could have done it there. Variant, Any, 
Optional or some non-union type can all make sense, depending on what 
we're up to.

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

Ooops -- the English word "extra" might not work quite the way I 
expected (see below for clarification).

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

Exactly. The mechanism you propose could still be useful and provided by 
the library as a utilty metafunction (which is what I was trying to say 
with "should be an extra metafunction" :-)).

Regards,
Tobias