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

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-01-06 13:32:09

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

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

Stjepan