"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufyvh59yx.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
| > 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?
correct.
| > 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 :-)
yeah, ok. I guess we could also demand that the range:: or iterator:: prefix is the name of a class.
I don't understand what you're getting at here.
| Ideally, you should have the semantic changes working in Boost well | before you submit the proposal. Remember "standardize existing | practice?"
Ideally yes. Do you find the standard process ideal? :-)
No. I'm just trying to help you get your proposal accepted, Thorsten.
Anyway, I feel we have enough experience and that a C++0x standard library without range support is going to hurt idiomatic C++0x.
Unfortunately, it doesn't matter what you think in this case. The range idiom isn't in widespread use yet, and I'm not convinced we know the right design for a range library yet. More importantly, I think many committee members will take the same point of view. On the other hand, if you have a good stable interface well before the meeting, there's at least a chance some committee members will have experience with it by the time we vote, and that would be a huge advantage. -- Dave Abrahams Boost Consulting www.boost-consulting.com