A Discussion of Tuple Syntax

bearophile bearophileHUGS at lycos.com
Wed Aug 21 06:35:31 PDT 2013


H. S. Teoh:

> This is adequately taken care of by std.typecons.Tuple, isn't 
> it?

> You can't make 'i' a runtime value because D is a 
> statically-typed language.

Yep. (From several persons explaining me similar things in 
answers to my posts it seems I am not expressing well that I know 
what I am discussing about. In future I will add notes to avoid 
this).


> Currently you could do:
>
> 	Tuple!(...) t1;
> 	auto a = t1[0];
> 	auto b = t1[1];
>
> Not as nice, certainly, but I wouldn't consider it a 
> deal-breaker.

> Currently we have:
>
> 	auto mult = (Tuple!(int,int) t) => t[0] * t[1];
>
> Not as pretty, but surely still readable and usable? Or am I 
> missing
> something?

> I didn't look in detail at your red-black tree example, or the 
> Huffman
> encoding example, but it would seem that currently, 
> std.typecons.Tuple
> more-or-less suffices for your needs, right? Except for some 
> syntactic unpleasantness, that is.
>
> Or is there something that *can't* be expressed in an adequate 
> way by the current Tuple that I missed?

See what I wrote at the beginning of the post:

>> We can live fine without a syntax to manage tuples, so strictly
>> speaking we need nothing

The semantics of tuples is simple and everything you can do when 
them is very easy to do in a language like C. The point of having 
tuples is to write code that is more readable, shorter, more 
expressive, a bit higher level. std.typecons.Tuple misses some 
expressiveness that some programmers think is handy to have, that 
I have listed in my post.


> What should happen if s is a runtime variable that may not have 
> the same
> number of words as the number of elements in the tuple on the 
> left-hand
> side? A runtime error?

> Again, what should happen if at runtime the lines have more or 
> less
> elements than the tuple on the left-hand side? A runtime error?

The answer I wrote in another post:

> Runtime boundary checks and tests are not needed if you unpack 
> a fixed-sized array:
>
> auto tup = Tuple!(int, string[2])(1, ["red", "blue"]);
> auto {x, [c1, c2]} = tup;
>
> Regarding the de-structuring of dynamic arrays, I think it's 
> not too much different than this:
>
> void main() {
>     int[] a = [10, 20, 30];
>     int[2] b = a;
> }
>
> If you compile and run it without switches, you get at run-time:
>
> object.Error: lengths don't match for array copy, 2 = 3
>
>
> While I receive no run-time errors if I compile with 
> -noboundscheck.


> Isn't this an auto-expanding tuple that Andrei didn't like?

I don't know. Ask to him.

Bye,
bearophile


More information about the Digitalmars-d mailing list