[boost] Re: [boost.range] post-review

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-16 01:30:57

Sorry to join the discussion late. ... Here are my thoughts:

------------------

"David Abrahams" <dave_at_[hidden]> 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_at_[hidden]> wrote in message:
> "David Abrahams" <dave_at_[hidden]> 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_at_[hidden]> 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