"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ullgj9dly.fsf@boost-consulting.com... | Daniel Frey <daniel.frey@aixigo.de> writes:
| > I agree. Also, the user can use namespace aliases to shorten calls, | > which doesn't work with range_. | > | > The difference for the user is also quite minimal, but using | > namespaces might also help to keep the library "cleaner" internally, | > as the algorithms in range:: can call each other without long names. | | Are we sure we want boost::range to be a namespace and not a class or | a template, forever?
no.
Following the tuples library convention, the namespace would be "ranges".
| I had a horrible thought: boost::range_traits::value<R>::type
:-) (btw, how would you follow that in the iterator lib? std::iterator_traits is already there)
Right.
The primary motivation for the namespace version seems to be shortening of names.
That doesn't seem very compelling to me.
So we can go from range_ to r::. so we save 3 chars. is that really worth the trouple?. Of course, other namespace can be much longer, but reasonable and short prefixes should be plenty; however it might also be worth something that a name can never be shortened, ie, it brings a certain consistency into the picture.
In this particular case, I think you could make a good argument that these traits (for iterators and ranges) are really the same, semantically. Maybe that solves some problems? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com