[boost] Re: [range] breaking changes

From: David Abrahams (dave_at_[hidden])
Date: 2005-04-05 16:54:24

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "Thomas Witt" <witt_at_[hidden]> wrote in message 
> news:d2rt3p$g1b$1_at_sea.gmane.org...
> | Thorsten Ottosen wrote:
> | > Dear all,
> | >
> | > Have anybody any last objections to breaking changes to boost.range:
> | >
> | >     boost::range_iterator<T>::type
> | >
> | > becomes
> | >
> | >     boost::range::iterator<T>::type
> | >
> | > and so forth. All code that relies on
> | > ADL inside the range library by overloading the functions begin() etc
> | > will need to be renamed range_begin() etc.
> |
> | Sorry I was unresponsive for a few days but I was travelling. I still
> | think this is the wrong way to do it. One reason is that it requires
> | every library X that wants to interface with the range lib to uglify its
> | interface by the range_ prefix.

Thomas makes a good point.

> yes, but in return the library only has two provide one overload
                                          ^^^-"to"
> of begin/end.

Meaning that you don't need a separate overload taking Seq const& just
to handle mutable rvalues.  That's good.  However, that benefit
doesn't depend on uglification.  We could use the same old names; the
interface would just not be useful for mutable rvalues unless the 2nd
overload were provided.

Another point is that the whole iterator/const_iterator thing is
artificial and broken anyway.  My work has evolved towards a "cursors
and property maps" arrangement where cursors encode position/traversal
and property maps encode access.  In that scheme there's no difference
between the cursors used when traversing constant and mutable
containers.  Of course, if you want to be able to get read access to a
non-const property map rvalue you may need two overloads for that
purpose.

We need to decide whether we're going to accept sub-optimal designs or
not.  If we want to use standard iterators (for which there are
obvious positive arguments) we are forced into some compromises that
we wouldn't have to accept if using cursors, and I think, Thomas, that
you'll have to accept that there's not really any completely
satisfying solution in C++03.

> |AFAICS there are two ways out of this
> |
> | a) X provides the unprefixed begin as well.
>
> how does that solve anything?

It allows clients of X to use it without boost.range.  Go back and
read Peter Dimov's posts in this thread: http://tinyurl.com/55j7b
(http://news.gmane.org/find-root.php?message_id=%3c004801c522aa%24ee97fd10%246501a8c0%40pdimov2%3e).
Shouldn't a Boost.Range-conformant range type be usable without the
dispatching functions in Boost.Range?

> | b) X requires the use of boost.range in order to have a "natural" interface
> |
> | I really think this is bad.
>
> a) or b) ?

I'm pretty sure Thomas means that either one is bad.  We aren't left
with any good choices.

> | If we want to have adl wrappers
>
> what is an ADL wrapper?

       template <class T>
       typename iterator<T>::type
       begin(T& x)
       {
           using somebody's::range_begin;
           return range_begin(x);
       }

Also known as a dispatching function.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com