"David Abrahams" <dave@boost-consulting.com> wrote in message news:ull7wga9b.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "Thomas Witt" <witt@acm.org> wrote in message | > news:d2rt3p$g1b$1@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%24...). | 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