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