Tuple namespace issue

From: Jaakko Järvi (jaakko.jarvi_at_[hidden])
Date: 2001-09-03 06:06:13

Hello, 

The tuple namespace issue is still hanging in the air. Here's one more
stab at it.
(Dave A, Peter !)

I think that there's a consensus that tuples are a general utility, and
basically should be in namespace boost. But along comes a set of 
additional names (tools for other library writers) that might be more
natural under a subnamespace.
Currently, the whole lib is in namespace boost.

At the end of this posting, there are some previous comments (Dave
Abraham's) about the different names in the library, and where they 
should reside.

Based on these comments, my suggestion is:

1. We reintroduce the namespace 'tuples'. 
(the plural form isn't perfect, but 'tuple' conflicts with the class
name
tuple.)

2. reference_wrapper, ref and cref will be defined in boost namespace
(They are a set of helpers that are not tuple specific. Peter D. has
already 
extracted this functionality out of tuples, and uses it in the bind
library)

3. All other definitions go into boost::tuples

3. The library lifts the following names:

  tuple, make_tuple, tie

into boost with the following scheme:

namespace boost {
namespace tuples {
 ...
 all the definitions
 ...
}
using make_tuple;
using tie;
using tuple;
}

These are the names that are meant to be used in everyday programs 
by any C++ programmer.
The names ignore, set_open(charT), set_close(charT),
set_delimiter(charT) are
such names as well, but there may be a danger for name clashes with
other libraries.
Rest of such names are functions/operators that are fetched based on the 
namespace of their arguments. The remaining names are metafunctions etc.
and not meant to be used by 'Joe the Programmer'.

So particularly, cons lists, and names like tuple_element<N>,
tuple_length<N>
can stay under boost::tuples (and their names can be changed to
tuples::element<N> ...), 
as well as the tuple specific io manipulators.
Further, streaming and comparison operators are under a subnamespace as
well.

The points in favor for using using declarations to lift the common
names into
boost namespace, instead of defining them directly there are:

- tuple and cons stay in the same namespace
- functions that operate on tuples/cons list can be 
  defined under boost::tuples.

Cheers, Jaakko

Previous comments:
----------------

> null_type

   fine in boost

> cons

   I'm not sure about this one. 
   
> tuple

   fine in boost

> tuple_element
> tuple_access_traits
> tuple_length

   Not documented, are they? This really needs to be done!
   (JJ: These are documented)
   
   But anyway, tuples::element, tuples::access_traits, tuples::length
would
   be fine or even better I suppose.

>
> ignore

    Perhaps a bit too generic a name for direct inclusion in boost

> get(cons<HT, TT>&)
> get(const cons<HT, TT>&)

    If these are really as specific as you say (the argument must be a
cons), then they're fine in boost.

> make_tuple() // 0, 1, 2, ... 10 argument versions

    fine in boost

> tie()        // 1, 2, ... 10 argument versions

    fine in boost, IMHO, but this one could be argued either way. tie is
    such a savings that boost::tuples::tie(...) is not too odious.

> operator<< and operator>> for cons lists
>
> operator<< and operator>> for tuple_manipulators

  If these only pick up the intended types, then OK.

> set_open(charT), set_close(charT), set_delimiter(charT)

  If these are tuple-specific, then I think they go in boost::tuples

> reference_wrapper
> ref
> cref

    ref and cref are too short, IMO, for boost::. I would be pleased
    for you and Peter Dimov to work out the future of the above names,
though.

> operator>   // these take two cons lists as arguments
> operator<
> operator==
> operator!=
> operator<=
> operator>=

Again, as long as they pick up the intended types only, OK. Of
course, if
cons<> goes into tuples::, these will have to go as well (Koenig
lookup).

> -------------------------
>
> So if tuples go back to a subnamespace, the questions are:
>
> 1. What is the name of the namespace (tuples or tuple?)

Better be tuples if tuple is going to be the name of a class.

> 2. Will the most common names remain in boost namespace?

I still hope so.

> 2.1. If yes, which, and are they defined in boost namespace
> or defined in boost::tuple(s) namespace and lifted to boost with
> using declarations.

No opinion yet.