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

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-01-07 13:00:47

On Jan 7, 2008 2:55 AM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> Stjepan Rajko wrote:
> > On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> >> 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.
>
> (-: Please excuse my forthright bluntness:
>

I welcome forthright bluntness :-)

> In case of the former it's a minor concern to just pass in that type.
> I'm pretty sure the resulting client code will read clearer (that is
> without having to dig up the docs).
>
> The latter seems to me as a misguided approach that encourages users
> to mess up the result type computation of their function objects.
>
> A user framework might still define its own Concept picking a custom
> type member (that will typically be one that does not interfere with
> those looked at by result_of) where appropriate.
>
> > 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.
>
> I disagree. Good code is self-explanatory. Good libraries encourage good
> style. Weird stuff stays weird and documenting it doesn't change it ;-).
>
> Maybe I'm just blind - but I see absolutely no benefit from attempting
> to deduce the result type over having the result type specified by the
> user.
>
>

I don't think you're blind - for the most part, I'm just throwing out
possible viewpoints to see if anyone else sees any validity behind
them, and to know what to recommend at the end of the review.  Thank
you for providing great arguments for your view - unless the author or
other reviewers feel strongly otherwise it seems like the most
reasonable way to go (and thanks to Joel for joining the discussion!).

Regards,

Stjepan