diff --git a/doc/design_decisions_rationale.html b/doc/design_decisions_rationale.html index ec05494..21f7457 100644 --- a/doc/design_decisions_rationale.html +++ b/doc/design_decisions_rationale.html @@ -1,3 +1,4 @@ + Design decisions rationale for Boost Tuple Library @@ -20,8 +21,8 @@ Tuples were originally under a subnamespace. As a result of the discussion, tuple definitions were moved directly under the boost namespace. As a result of a continued discussion, the subnamespace was reintroduced. The final (I truly hope so) solution is now to have all definitions in namespace ::boost::tuples, and the most common names in the ::boost namespace as well. -This is accomplished with using declarations (suggested by Dave Abrahams): -
namespace boost {
+This is accomplished with using declarations (suggested by Dave Abrahams):

+
namespace boost {
   namespace tuples {
       ...      
     // All library code
@@ -32,8 +33,8 @@ This is accomplished with using declarations (suggested by Dave Abrahams):
   using tuples::tie;
   using tuples::get;
 }
-

-With this arrangement, tuple creation with direct constructor calls, make_tuple or tie functions do not need the namespace qualifier.
+
+

With this arrangement, tuple creation with direct constructor calls, make_tuple or tie functions do not need the namespace qualifier. Further, all functions that manipulate tuples are found with Koenig-lookup. The only exceptions are the get<N> functions, which are always called with an explicitly qualified template argument, and thus Koenig-lookup does not apply. Therefore, get is lifted to ::boost namespace with a using declaration. @@ -54,9 +55,9 @@ The rationale for not using the most natural name 'tuple' is to avoid having an Namespace names are, however, not generally in plural form in boost libraries. First, no real trouble was reported for using the same name for a namespace and a class and we considered changing the name 'tuples' to 'tuple'. But we found some trouble after all. -Both gcc and edg compilers reject using declarations where the namespace and class names are identical: +Both gcc and edg compilers reject using declarations where the namespace and class names are identical:

-
namespace boost {
+
namespace boost {
   namespace tuple {
     ... tie(...);
     class tuple; 
@@ -66,13 +67,13 @@ Both gcc and edg compilers reject using declarations where the namespace and cla
   using tuple::tuple; // error
     ...
 }
-

+
-Note, however, that a corresponding using declaration in the global namespace seems to be ok: +

Note, however, that a corresponding using declaration in the global namespace seems to be ok:

-
+

 using boost::tuple::tuple; // ok;
-

+

The end mark of the cons list (nil, null_type, ...)

@@ -80,14 +81,15 @@ using boost::tuple::tuple; // ok;

Tuples are internally represented as cons lists: -

tuple<int, int>
-
-inherits from -
cons<int, cons<int, null_type> >
+
tuple<int, int>
+
 
+
inherits from

+
cons<int, cons<int, null_type> >
 

 
+

 null_type is the end mark of the list. Original proposition was nil, but the name is used in MacOS, and might have caused problems, so null_type was chosen instead.
-Other names considered were null_t and unit (the empty tuple type in SML).
+Other names considered were null_t and unit (the empty tuple type in SML).

 

 Note that null_type is the internal representation of an empty tuple: tuple<> inherits from null_type.
 

@@ -95,22 +97,22 @@ Note that null_type is the internal representation of an empty tupl
 
Element indexing

 
 

-Whether to use 0- or 1-based indexing was discussed more than thoroughly, and the following observations were made:
+Whether to use 0- or 1-based indexing was discussed more than thoroughly, and the following observations were made:

 
 
-Tuple access with the syntax get<N>(a), or a.get<N>() (where a is a tuple and N an index), was considered to be of the first category, hence, the index of the first element in a tuple is 0.
+
Tuple access with the syntax get<N>(a), or a.get<N>() (where a is a tuple and N an index), was considered to be of the first category, hence, the index of the first element in a tuple is 0.

 
 

 A suggestion to provide 1-based 'name like' indexing with constants like _1st, _2nd, _3rd, ... was made.
 By suitably chosen constant types, this would allow alternative syntaxes:
 
-
a.get<0>() == a.get(_1st) == a[_1st] == a(_1st);
-

+
a.get<0>() == a.get(_1st) == a[_1st] == a(_1st);
+

 
-We chose not to provide more than one indexing method for the following reasons:
+
We chose not to provide more than one indexing method for the following reasons: