From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-01-06 15:12:47
On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> Stjepan Rajko wrote:
> > 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).
Sure - although the library could offer something along the lines of
> > 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.
I agree that being able to specify the return type explicitly would be
very useful, precisely because you could use function objects that are
not result_of/result_type compatible, or override the return type even
if one is specified by the function object. I can see overriding it to
boost::any or some other "common denominator" as a frequent use case.
> 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.
>From what I can see, it buys simplicity when the use case is not
complicated (the return type is available through result_type or
result_of and does not change), or when you really want to leave it to
the function object to specify what the return type should be.
Granted, all of the proposed solutions for return type deduction seem
slightly imperfect / inelegant, but as long as the behavior is clearly
explained in the documentation they could be useful.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk