Re: [boost] Boost.Range naming

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-06-22 09:07:12

"David Abrahams" <dave_at_[hidden]> wrote in message 
news:u64w6a66h.fsf_at_boost-consulting.com...
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
|
| > "David Abrahams" <dave_at_[hidden]> wrote in message
| > news:ufyvh59yx.fsf_at_boost-consulting.com...
| > | "Thorsten Ottosen" <nesotto_at_[hidden]> 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