On Sat, Apr 5, 2008 at 9:15 PM, Eric Niebler <eric@boost-consulting.com> 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