From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-04-07 12:14:57
On Sat, Apr 5, 2008 at 9:15 PM, Eric Niebler <eric_at_[hidden]> wrote:
> Daniel Walker wrote:
> > Is this anything like what you're looking for?
>
> Yes, it works, it's hideously ugly and complicated, and nobody writes
> function objects like this in practice. It proves my point.
I agree that writing function objects that support argument dependent
return type deduction will be much more attractive with a result_of
implemented on top of decltype. The current result_of supports
automatic return type deduction for functions, function pointers, etc.
However, function objects are a special case, which requires the
author of the functor to advertise the return type either through
result_type or, for argument dependent functors, through result<>.
Now, with decltype this heuristic is no longer necessary and functors
can be handled fully automatically. Anything that requires manual
intervention is hideously ugly compared to that! ;-)
Also, surely the result<> convention is not That complicated. It's
been the standard practice (and in fact the only supported convention)
for argument dependent return type deduction with result_of for, um,
five years or more I believe. So, everybody who writes result_of
compatible functors with argument dependent return types has written
something like my example. It's been the only choice.
>
> > Note that there are specializations for result<> corresponding to
> > exactly the way the operator()s are overloaded, and the overloads use
> > result<> to specify they're return types. In a situation like this, I
> > find it easier to try to keep a specific one-to-one correspondence
> > between result<> specializations and overloads. It's a bit of a
> > manually convention, but as you both point out, without decltype
> > return type deduction can be tedious by nature.
>
> "It's a bit of a manual convention" is precisely my point. Not only is
> it manual and tedious, but it's a convention that (hardly) nobody else
> follows. In generic code, I can't rely on some arbitrary function object
> Foo to do anything reasonable when passed a reference wrapper.
Then I'm not sure that I see your motivation for using reference
wrappers in the first place. What exactly do you gain from it?
>
> The general issue is: given an unknown binary function object F, an
> object L which is known to be an lvalue, and an object R known to be an
> rvalue, how do I invoke F in C++0x? F(L,R) might do the wrong thing with
> the rvalue, and F(ref(L),R) might not compile.
>
> Only questions, no answers,
Well, I think you're making headway elsewhere in this thread. It looks
like you're getting closer to an answer!
Daniel