[boost] Re: [range] breaking changes

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-04-06 05:54:16

"David Abrahams" <dave_at_[hidden]> wrote in message 
news:ull7wga9b.fsf_at_boost-consulting.com...
| "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.

hm...I don't think it is particularly ugly compared to so many other hacks.
Once a protocol for ADL hooks are provided, it will seem quite natural
to users.

| > 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.

but now you introduce the ADL lookup problem again.

| 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.

How would I traverse a range in that framework?

| 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,

How does ADL lookup change in the new framework you're working on?
I don't see how it relates to the the proposed changes to boost.range which
has as its main purpose to enable ADL lookup while using qualified notation.

| > |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?

well, for vector<int> v; you can use v.begin() etc. for pair<I,I> p, you
can use p.first etc. So I don't think that makes much sense; boost.range
is a framework---either you use it or you don't.

| > | 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.

that's what I figured too.

-Thorsten