"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. | > 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? yes. | 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? :-) Anyway, I feel we have enough experience and that a C++0x standard library without range support is going to hurt idiomatic C++0x. There are some potential new ideas that you have been working on (cursors + property map, the stuff about more general ranges from tuples, fusion) which might impact the proposal. However, as long as we make sure those things can be put into the framework, I don't see the problem about submitting a proposal for the next meeting. | > 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?" hm...to much direct Danish in there:-) I meant "at the same time". -Thorsten.

"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

"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jgm77rf.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "David Abrahams" <dave@boost-consulting.com> wrote in message | > news:u64w6a66h.fsf@boost-consulting.com... | > | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | > | | > | > 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. | | Bad idea IMO; it means nobody can adapt a 3rd party type or a builtin | to make it fit the Range concept. It's the same reason we use traits | instead of requiring nested type names. yeah, seems bad. I don't understand how you would define std::iterator::value<T>::type etc then? | > | 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. | | It doesn't matter how extensively it has been discussed if it | hasn't been implemented and used widely. | | > Anyway, I plan to write the proposal in several "levels" s.t. the | > committee can stop at whatever level it feels is appropriate. | | Not a great idea either, IMO. If you give the committee too many | options, people tend to either get confused, or get mired in arguments | about which one to choose. A simple proposal stands a much better | chance. perhaps. At the Lillehammer meeting Walter Brown presented his idea of adding const_begin() member to the containers and the possibility of having free-standing begin()/end() functions. So apparently experience was not an issue with this stuff. People liked the idea even though he didn't even mentioned the more elaborate boost.range. Then I said that I would like to work with Walter on this because of my experience from boost with this stuff. It turned out that I became more or less the sole proposer. | I have been trying to help you, but I'm feeling rather discouraged | now. Unless you tell me you want more of this kind of input, I'll | just stop now. Sorry if I sounded arrogant (as usual). I've quite stressed at the moment. I always appreciate any feedback, even if I don't agree with the feedback. best regards -Thorsten

"David Abrahams" <dave@boost-consulting.com> wrote in message news:u8y1137mz.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | > yeah, seems bad. I don't understand how you would define | > std::iterator::value<T>::type etc then? | | You wouldn't. That doesn't work. ok, then maybe it is better to stick with range_iterator etc. -Thorsten