On 10/16/2015 3:28 AM, Neil Groves wrote:

On 16 October 2015 at 06:31, Marcel Raad wrote:

...

Edward Diener-3 wrote

...

Similarly if any other library depending on 'iterator' needs these changes on 'master' it needs to be co-ordinated with 'iterator'.

Sorry for causing so much trouble! I think Boost.Range was the only library that broke because it depended on boost/iterator/iterator_concepts.hpp including boost/detail/iterator.hpp. Unfortunately that affected other libraries depending on Boost.Range.

Don't worry too much. The co-ordination across modules for these interface-breaking changes is always challenging. I'll merge from Boost.Range from develop to master over the weekend.

Let's co-ordinate that together when you do. You will need me to push Marcel Raad's changes on 'iterator' when you do, unless you have write priveleges for 'iterator' and can push those changes yourself when you update 'range'.

On 10/16/2015 11:10 AM, Robert Ramey wrote:

On 10/15/15 9:50 PM, Edward Diener wrote:

...

I have pushed a number of changes to iterator from 'develop' to 'master' for the next release.

A series of these changes on 'develop', by Marcel Raad, is an attempt to remove from 'iterator' the use of the deprecated headers 'boost/iterator.hpp' and 'boost/detail/iterator.hpp' in favor of using 'std::iterator' directly instead of 'boost::iterator' and 'std::iterator_traits' and 'std::distance' directly instead of 'boost::detail::iterator_traits' and 'boost::detail::distance'. Essentially these changes mean that any other library using 'iterator' classes would fail if they attempted to refer to 'boost::iterator', 'boost::detail::iterator_traits', or 'boost::detail::distance'.

The serialization library depends heavily on functionality only present in boost/iterator. This sounds like a recipe for surprises

Only if serialization directly specifies 'boost::iterator', 'boost::detail::iterator_traits', or 'boost::detail::distance'. If it just uses the usual iterator templates the change would not affect it.

On 10/16/2015 2:05 PM, Robert Ramey wrote:

On 10/16/15 10:51 AM, Edward Diener wrote:

...

On 10/16/2015 11:10 AM, Robert Ramey wrote:

...

On 10/15/15 9:50 PM, Edward Diener wrote:

...

I have pushed a number of changes to iterator from 'develop' to 'master' for the next release.

A series of these changes on 'develop', by Marcel Raad, is an attempt to remove from 'iterator' the use of the deprecated headers 'boost/iterator.hpp' and 'boost/detail/iterator.hpp' in favor of using 'std::iterator' directly instead of 'boost::iterator' and 'std::iterator_traits' and 'std::distance' directly instead of 'boost::detail::iterator_traits' and 'boost::detail::distance'. Essentially these changes mean that any other library using 'iterator' classes would fail if they attempted to refer to 'boost::iterator', 'boost::detail::iterator_traits', or 'boost::detail::distance'.

The serialization library depends heavily on functionality only present in boost/iterator. This sounds like a recipe for surprises

Only if serialization directly specifies 'boost::iterator', 'boost::detail::iterator_traits', or 'boost::detail::distance'. If it just uses the usual iterator templates the change would not affect it.

So namespaces aren't changed at all? I notice I'm using things like boost::iterator_value, boost::iterator_core_access, ... etc. (off topic - In hindsight it seems a mistake to put them into the root namespace). I don't happen to use #include but isn't this a common idiom (convenience headers) in boost libraries? Are you sure you want to make a special case here?

First of all it's not really my change. Marcel Raad has pushed it based on previous comments in boost/iterator.hpp and boost/detail/iterator.hpp that these headers were deprecated. Namespaces aren't changed at all. All the boost iterator stuff is still boost::iterator_xxx etc. The header boost/iterator.hpp is a convenience header but all it does is put std::iterator in the boost namespace. Ditto for boost/detail/iterator.hpp just putting std::iterator_traits and std::distance into the boost::detail namespace. I don't know the history of any of this. I am working with 'iterator' on sufferance <g> because it doesn't look like any maintainer is paying the slightest attention to it and it still remains a key Boost library which needs some maintenance. If Marcel Raad, or some other expert, would like to be the new official maintainer of 'iterator' I would be more than happy.

Robert Ramey wrote:

I understand all this. Seems to me that a mistake was made when these headers got transformed into forwarding headers to the standard library.

These headers predate the Iterator library. They were never what you want them to be. They never got transformed from what you want them to be into something else. They have always been a compatibility hack for deficient standard libraries, a hack that is no longer relevant.