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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-06 14:20:48

Stjepan Rajko wrote:
> On Jan 6, 2008 7:34 AM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
>> Steven Watanabe wrote:
>>> Tobias Schwinger <tschwinger <at> isonews2.com> writes:
>>>> Of course there are no pointers to templates, so using a function
>>>> pointer for anything but the default is pretty pointless. So is trying
>>>> to handle varying result types -- maybe the result type should be passed
>>>> in with another template parameter?
>>> I'd rather leave it as result_of<F()>::type.
>> Actually 'result_of<F()>::type' determines the result of the nullary
>> call to F. I don't think I like this sort of "result_of abuse"... The
>> correct usage would be 'result_of<F(MPLConstant)>::type' but it's
>> pointless since 'MPLConstant' varies and so may the whole type expression.
>>
>> So, if you insist on deducing the result type from the function object
>> (instead of having it specified explicitly) my vote is 'F::result_type',
>> however, I still find another template parameter more appropriate for
>> the following good reasons:
>>
>> o The function object can work fine with result_of in a non-'switch_'
>>     context. The cases can return different things as long as they are
>>     convertible to the result of 'switch_', and
>>
>> 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.

Regards,
Tobias