Tuple literal syntax + Tuple assignment

[Simen kjaeraas]

bearophile <bearophileHUGS at lycos.com> 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