
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u64w6a66h.fsf@boost-consulting.com... | "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. make value<T>::type etc nested classes of the iterator/range class. | > | 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. I'm not sure what beside Erics et al.s range_ex you want to stabilize that hasn't already been discussed extensively. Anyway, I plan to write the proposal in several "levels" s.t. the committee can stop at whatever level it feels is appropriate. -Thorsten