RE: [boost] Re: Tuple library accepted

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-06-28 08:18:57

 Peter Dimov wrote:
> 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.

get<0>(t) is very much like t[0]. In fact, I would prefer "at" name, e.g.
at<0>(t), and this one has even more close parallel to the index notation.
BTW, I would really like tuple library to support container-like view on the
tuple objects, e.g. front(t), back(t), push_front(t, something),
push_back(t, something), etc.

> 
> So neither "consistency with arrays" nor "consistency with 
> bind libraries and std::pair" is a convincing argument. 
> Both schemes are equally valid.

Well, besides "consistency" in general, there is also another side of the
issue - direct interaction with another components/libraries. As for the
labma/bind libraries, tuples usage there is just an internal implementation
detail, and IMO, as far as it's never exposed to the user, it might be ok to
have different indexing schemes there. But suppose, for example, that one
day tuple, instead of (or in addition to) 'tuple_element_type', will provide
a typelist of types of its elements (which I expect to happen). Now,
'typelist' is a direct compile-time analog to std::list, and zero-based
indexing is a "must have" requirement for it, and it would be better if at
that moment we don't have to explain to users of the library that (and why)
'tuple_element_type<1, Tuple>::type' and 'at<1, Tuple::element_types>::type'
return different types.

Aleksey