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
Sorry to join the discussion late. ... Here are my thoughts: ------------------ "David Abrahams" <dave@boost-consulting.com> wrote: 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.
We cannot use the same namespace for size as a function and
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. metafuntion
nor bring them into the same scope.
The smallest change is not to change the iterator library and
Yes, but I believe you should use 'size_type' instead. 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