"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.
| 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. 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. Regards, -- Dave Abrahams Boost Consulting www.boost-consulting.com