
From: "Jonathan Turkanis" <technews@kangaroologic.com>
"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
The duplication, "..._type<...>::type," seems silly, though, doesn't it? Having said that, the "_type" can simply be construed as saying that the type is a type generator, and the "::type" as the generated type. What's more, while the entire expression is meaningful, the class template isn't well named. That is, boost::iterators::value<I> is less helpful than boost::iterators::value_type<I>. Then, knowing that such a type is a type generator, you apply it by accessing the "type" nested type. So, I'm now thinking it isn't so bad to duplicate "type" in the expression, though it still would be nice to eliminate it.
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
A convention that you add a trailing underscore to keywords should be easy enough to administer and remember. However, the type name isn't very meaningful outside the full expression.
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.
I agree.
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' --
I think that's a really good convention. For example, boost::tuples is the namespace for the code from which one can create tuple types. That is, various specializations of boost::tuple. However, this convention is the opposite of the detail namespace which I think should be named "details" instead since it holds more than one implementation detail. (No, I don't expect to see that change, but it would be more sensible to me.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;