"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uhdfznybq.fsf@boost-consulting.com... | | I don't remember whether I expressed these concerns earlier, but I | don't think most of the names ought to have been in namespace boost. | For example, names like range_xxxx are crying out for a range:: | namespace in which to put a component called xxxx. Also, names like | begin and end are so general and important that I think they should | have been in boost::range, with perhaps an optional header that brings | them into namespace boost via using declaration.
This came up in the long discussion we had some time ago about ADL and names like begin()/end().
I think the consensus was to use the form
range::iterator<T>::type range::value<T>::type iterator::value<T>::type iterator::difference<T>::type
So I take it you just haven't had the time to make the change yet?
The only sorry thing about this is that in namespace std we already have a class called iterator. ^ template ;-)
Yep, especially sorry because it's so useless ;-) OTOH we could give it an additional default argument so that when it is used as a unary metafunction it has the new semantics :-)
When I write the standard proposal, I will go for the range namespace + merge iterator<T>::type and const_iterator<T>::type.
You mean, you'll be proposing std::range::whatever? Ideally, you should have the semantic changes working in Boost well before you submit the proposal. Remember "standardize existing practice?"
There are a number of larger changes we have already been considering; it might make sense to make use of the range namespace in the sane round for 1.34.
"Sane round?" -- Dave Abrahams Boost Consulting www.boost-consulting.com