Sorry to join the discussion late. ... Here are my thoughts: ------------------ "David Abrahams" <dave@boost-consulting.com> wrote:
We chose "iterator_value" et al because we couldn't be sure that someone wouldn't need to make another concept Q in boost that had its own, separate notion of an value_type. If you then had a type X that fulfilled both the Iterator and Q concepts, how would you specialize value_type_of?
There could be trouble even if no type fulfills both concepts: in general, it may not be possible for the two concepts to share a single default implementation of the metafunction. That does not seem to be a problem in the current case, however. ------------------ "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message:
"David Abrahams" <dave@boost-consulting.com> wrote:
| | boost::iterators::value<I>::type | boost::iterators::reference<I>::type | | boost::ranges::value<R>::type | | and so forth?
good idea to rename value_type<I>::type value<T>::type :-) I guess we should do that with
range::size<R>::type range::difference<R>::type
I don't like dropping the '_type' here -- One of the main advantages of a naming convention is that you can figure out what the name should be without consulting the docs. Consider a nearly identical situation in my iostreams library (to be reviwed later this month). Instead of typename Source::char_type I use boost::io::char_type<Source>::type If we were to drop the '_type' we would have boost::io::char, which is illegal. Same for int_type. Of course, the convention could be to keep '_type' if necessary, or to use a trailing underscore, but I'd rather have the easy-to-remember convention that the metafunction has the same name as the traditional nested type. "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message:
I'm feeling less and less comfortable with the namespace version. Shorter names don't seem to be an issue.
Yes.
Namespaces on concepts seems to be an issue.
Namespaces on a concept don't bother me at all. For each of a concept's associated types -- when possible -- there should be an official metafunction defining the association. This metafunction has to be in *some* namespace or other.
We cannot use the same namespace for size as a function and metafuntion nor bring them into the same scope.
Yes, but I believe you should use 'size_type' instead.
The smallest change is not to change the iterator library and therefore I will use the prefix range_ for my metafunctions unless there are heavy objections.
I think range_xxx and ranges::xxx are about equally good. I don't really like the convention of forming namespace names by adding 's' -- although I don't have a better idea -- so perhaps I'd choose range_xxx. Jonathan