Better tuples

[bearophile]

Thank you for your comments Philippe Sigaud, and sorry for my slow answer, I was quite busy.


> just add either
> @property size_t length() { return Types.length; }
> or
> immutable length = Types.length

Better:
enum length = Types.length;


> opSlice() is not defined for AA, so whe not use it to return a range?
> auto range = aa[]; // lazily produce (K,V) pairs

This is cute but I prefer something like AA.byItem() because it's more explicit and readable.


>Inserting elements, rotating tuples, reversing them, etc. Even mapping polymorphic functions on tuples and reducing them, though I don't think these should be part of any standard library.<

I think that slicing and concatenation are operations common enough to deserve to be built-in in the stdandard tuples (slicing is already present, and my old Record type has concatenation too).

Reverse of tuples is less commonly useful, and if tuples become well iterable then you just need a generic reversed:
tuple(reverse(sometuple))
So a reverse specific for tuples is not useful...


>>- "in" operator for tuples (as for arrays).

>Yes, and that seems easily implementable. I use this:<

Yep, but Walter doesn't like this semantics :-)


>> - Optional: Zip and other pairing ranges to yield tuple (currently for
>> efficiency they yield a pair of pointers. But this breaks abstraction. Using
>> a more common data structure has significant advantages. The compiler can
>> recognize the idiom and in some cases can avoid the creation of the Tuples
>> that Zip produce.

>I don't like the idea of compiler magic,

The idea of making the compiler more aware and able to optimize the zip range better is positive, it's not magic, it's a compiler better able to digest the language idioms, it's a natural thing. We have done this a bit in the ShedSkin compiler because in Python code zip is used often.


> but I do like the idea of having a
> Zip that uses the standard structure: tuples. Its easier to inferface with
> other functions this way. The Proxy from phobos zip is good for sorting
> (which is why Andrei defined it this way, I guess), but it's a pain to use
> otherwise, because it's a one-of-a-kind struct that cannot be fed to other
> functions.

I agree :-)


> Once again, you can use ._x, .field or .expand for that.

The _x and .expand are not explained in this page, I didn't know about them:
http://www.digitalmars.com/d/2.0/phobos/std_typecons.html


> Tuple code list bug 2800 as a blocker for this.

Thank you. It's a bug reported by Andrei so probably he has tried the same idea :-)


> foreach(index, item; tup.expand)
>     writeln(item);

I prefer tuples to work more like arrays, so no expand. Less syntax to remember and code to write.


> Wheww.
> OK, at the risk of repeating myself, why not like this?
> void main() {
>     auto t = tuple(1,"abc");
>     foo(t.expand);
>     auto t2 = tuple(3.14, 1, "abc");
>     foo(t2.field[1..$]);
> }

OK, the apply() is not so necessary.

Thank you for all your answers, you have improved some of my ideas :-)

Bye,
bearophile