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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-05 19:26:07

Steven Watanabe wrote:
> AMDG
> 
> Tobias Schwinger <tschwinger <at> isonews2.com> writes:
> 
>> dan marsden wrote:
>>> Why is the fall through behaviour to throw an exception?
>> I too tripped over this one, yesterday.
>>
>> <snip>

> The other option is an assertion.  Is that any better?

I think the "default default behavior" should be to use the default 
constructor. This approach works nice with Any, Variant and Optional.

> Or should a void return type be a special case?

If 'Default's result type is 'void' although something else is expected, 
we should assert it never actually returns at runtime (note that it is 
possible to detect the result type with an overloaded comma operator and 
without requiring 'Default' to work with 'result_of' -- might also be 
faster). If assertions are disabled the behavior should be unspecified 
in that case.

<snip>

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

Regards,
Tobias