Re: [boost] Re: Tuple library accepted

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-28 12:13:14

On Thursday 28 June 2001 08:26, you wrote:
> From: "Kloss, Burkhard" <Burkhard.Kloss_at_[hidden]>
>
> > <snip - lot's of good arguments>
> >
> > >As a programmer, I use both FORTRAN (1 based by default) and
> > >C/C++ (0 based) and know I have to change over
> >
> > True - but it's one thing to switch indexing regimes when switching
> > languages. Within a language it should be consistent.
>
> Even within a language, sometimes a consistent indexing scheme is
> counter-intuitive. Function arguments for me logically start from one, not
> zero; there is no conflict because I don't use [] to access them.
>
> Every bind/lambda library I know of uses free1/arg1/_1/whatever1 to refer
> to the first argument. The standard library uses bind1st to bind the first
> argument, and std::pair's first element is called 'first.'
>
> Of course every array-like object that is accessed using operator[] uses
> zero-based indexing.
>
> The problem with tuple is that it doesn't fall in either class: if I have a
> tuple t, I can use neither t[0] nor t.first to refer to its first element.
>
> So neither "consistency with arrays" nor "consistency with bind libraries
> and std::pair" is a convincing argument. Both schemes are equally valid.
>
> --
> Peter Dimov
> Multi Media Ltd.

Both schemes are also compatible. "First" doesn't imply 1-based indexing, it 
implies the first element (this has been said before). For the purpose of 
using tuples in a compile-time loop, it should likely be zero-based (it would 
be surprising to have a 1-based loop). That would make tuple's "get" 
zero-based. However, there is nothing preventing the use of symbol names 
_1st, _2nd, _3rd, etc (or _1, _2, _3 or first, second, third) to access tuple 
elements. 

My vote would be to use zero-based indexing and have _1st, _2nd, _3rd, etc. 
in a separate header. There should not be any confusion because "first" means 
the first element regardless of any number associated with it.

If this is adopted, we should bicker about the names of these symbolic 
constants now so that all libraries using them will be consistent (i.e., 
binders and lambda have different names).

        Doug