Tuple library accepted

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-27 12:07:17

The Tuple library is accepted by Boost.  In addition to the public comments 
in favor of the library, there was one private comment urging acceptance.

Thanks for the detailed reviews from several members.

Lots of minor issues were mentioned, and Gary and Jaakko have replied as to 
how they intend to resolve these.

Some issues required more discussion.  I've tried to summarize these issues 
below, and included the resolutions:

* Nil issues:

[Douglas McGregor]
Nil (null) will not be included in function at this time. It is too
controversial to sneak in as part of 'function' (if we were all U.S.
Congressmen things would be different...).

Tuples appears only to need a sentinel type. I'd suggest 'null_type' to
avoid any collisions with MacOS, and move it into a detail namespace.

I'll reintroduce the notion of a generalized 'null' again after I have had
more experience with it.

[Gary]
Going to "null_type" would be fine. It's not a detail, so moving it to an
implementation detail namespace would be a mistake. We'll add some
documentation for its use. (LL uses it.) Then if boost ever has a
boost::null we can switch to that.

* Namespaces:  Should there be a namespace tuples[s] within namespace boost 
and how should it be spelled?

[Dave Abrahams]
Hmm. I would much prefer, in that case, to see tuple directly in boost.
Subnamespaces should be for domain libraries (e.g. boost::python,
boost::graph), as we have discussed earlier
(http://groups.yahoo.com/group/boost/message/7349). Tuples are not a 
domain,
but a utility.

[Gary]
Fine by us. I was concerned that there would be another boost library with
"tuples", "nil", "const_nil", "ignore", "cref", "ref" and that adding more
names to the global namespace "boost" would cause other library submissions
grief. But its easier for us if its just in "boost". (Note: nil will be
changed as noted earlier.)

* Deprecate: tie (in utility.hpp).

[Beman]  I've added a note in the utility docs to that effect.

* Indexing and naming issues:

(It's hard from reading the back postings to see the final resolution on 
this.  Was the decision that the usage was index-like and so should be 0 
based, or name-like and so should be 1 based? Gary? Jaakko?

--Beman