bearophile <[email protected]> wrote:
In my opinion it's good for a built-in D tuple to be a structural type.
This also means you are allowed to perform an == among two tuples of
different length (the result is known statically to be always false).
I understand (and agree to) the opinion that tuples should be structural
types, but why allow comparison of tuples of different lengths?
Walter:
A lot of it foundered on what the syntax for tuple literals should be.
The top
of the list is simply enclosing them in ( ).
This is a bad idea. It has caused troubles in Python because of the
singleton syntax (tuple with 1 item).
One solution is to use a special unambigous delimiter to denote tuples,
like (a similar solution is used in the Fortress language):
(|1, 2, 3, 4|)
Otherwise a good solution is to use a name:
record(1, 2, 3, 4)
I prefer the record() solution, but the first solution too acceptable.
Yeah, ( T... ) is not a good general tuple syntax. I believe auto( ) is
a free syntax in D, and thus could be used for tuples. Thinking more
about it, I am no longer as sure.
auto (car, cdr...) = expr;
I really like this.
Regarding field names for tuples, I have used Python and I like the
optional names of D tuples (records). In some situations you don't need
names, but in other situations field names are handy and help avoid
bugs. In Python code that processes and uses tuples contains too many
[0] [1] [2] etc that aren't readable and are bug-prone.
But a good management of such names asks for the names to not change the
type of the tuple, this is why I talk about structural typing for
records.
I wrote a Tuple implementation for D that supports structural typing:
http://pastebin.com/qeYKa5GZ
(see line 58-60 for proof)
This is a simple proof-of-concept, so don't expect anything impressive
from it.
--
Simen
