"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uk6mga3yb.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "David Abrahams" <dave@boost-consulting.com> wrote in message | > news:u1x8pceqw.fsf@boost-consulting.com... | > | | > | What is the rationale behind this name? It seems unintuitive to | > | me, and what's more, unneccessary. | > | > why? | | Unintuitive: it's not clear what The "result" part refers to. It's | such a generic word when applied to a (meta)function that it lacks | obvious semantic content... it's almost like naming the max fucntion | "result_of_max."
well, I think const_if_arg_is_const_mutable_otherwise_iterator<T>::type was considered.
ideas are welcome.
range::iterator<T>::type
| > | Shouldn't range_iterator<T const>::type just be | > | range_const_iterator<T>::type? | > | | > | If not, why not? | > | > container::const_iterator is the parallel. | | That doesn't explain anything (to me). What I was asking was: why | provide this oddly-named metafunction when people could just make the | inquiry using range_iterator with a const argument?
I guess the design could havebeen that way; but we don't say container< const T >::iterator to get container<T>::const_iterator.
That's because (among other things) a container of const T is illegal. And it's the wrong analogy anyway. The analogy would be container<T> const::iterator if such a syntax were legal. Accessing nested data types directly is usually wrong for generic code anyway, so I'm not sure that makes such a great precedent to follow. -- Dave Abrahams Boost Consulting www.boost-consulting.com