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