Re: [boost] range/iterators/algorithms return type deduction (was: Re: range_ex: status?)

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-06-24 12:51:10

On Tue, Jun 24, 2008 at 12:12 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> Steven Watanabe wrote:
>> Can't you use result_of?
>
> As far as I can see, the current boost::result_of implementation doesn't
> use decltype or typeof.

The boost::result_of on svn trunk uses decltype when
BOOST_HAS_DECLTYPE is defined. This happens automatically for gcc
versions after 4.2.

> I suppose implementing decltype on top of typeof is not a big problem
> (you only need to check whether the expression is a reference or not)
> however both have problems with mangling when used in a return type, at
> least in GCC.
> That basically means you can't always rely on them working. I thought
> decltype didn't have those mangling problems, looks like it is a regression.
>
> As for the correct way to do that, I suppose it should be possible to
> tell boost::result_type with a macro definition to use Boost.Typeof,
> which in turn can use either native or emulation.

This might not be a bad idea for compilers that lack decltype -
perhaps it could be offered as an alternative to the TR1 heuristic. Of
course, this would break compatibility with TR1 and C++0x in some
cases, which might cause more problems than it solves. But if the
various alternative result_of implementations are documented properly
(and perhaps placed in separate namespaces) then it shouldn't be so
bad.

>
> However range_ex only forwards algorithms and adaptors to Boost.Iterator
> and maybe the standard library. Maybe it's these that ought to use
> boost::result_of in the first place?

This is an excellent point. The standard library essentially relies on
concepts like SGI's AdaptableUnaryFunction, which requires expressions
of the form funtor::result_type, funtor::argument_type, etc. I think
it would be useful to have <functional> and <algorithm>
implementations that support an alternative concept framework
requiring expressions of the form result_of<functor(T)>::type and
argument_of<functor(T)>::type.

Daniel Walker