"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