Tuple assignment

[Denis Koroskin]

On Thu, 07 Oct 2010 11:42:06 +0400, Brad Roberts <braddr at puremagic.com>  
wrote:

> On 10/6/2010 11:58 PM, Walter Bright wrote:
>> Russel Winder wrote:
>>> Python may be the best base to compare things to as tuple assignment  
>>> has
>>> been in there for years.
>>>
>>> Pythons choice is not a car/cdr approach but an exact match approach.
>>> so if t represents a tuple datum or a function returning a tuple:
>>>
>>>         x = t
>>>
>>> then x is a tuple -- remembering that variables are all just references
>>> to objects implemented via keys in a dictionary, and:
>>>
>>>         a , b , c = t
>>> or
>>>         ( a , b , c ) = t
>>>
>>> is tuple assignment where now t is required to be a tuple of length 3.
>>> cf.
>>
>> The first thought was to make it an exact match approach. Andrei  
>> thought that
>> the car/cdr one was better, though, and I find it intuitively  
>> appealing, too.
>> Perhaps Python missed an important use case?
>>
>> Or perhaps the ambiguity as to whether the last item gets to be a value  
>> or
>> another tuple is too much.
>
> I think the ambiguity should be avoided.  There was one language I used  
> ages ago
> that used a token to signal the use of the last arg as a 'rest' usage.   
> If I
> remember right, it used:
>
>   (a, @b) = aggregate; // a = aggregate[0], b = aggregate[1..$]
>
> It also allowed: (a, @aggregate) = aggregate; // essentially a pop  
> operation.
>
> That said, it was a weakly typed language, so it's application to D has  
> to be
> taken with an appropriate dose of salt.  For D, I think using the @  
> would clash
> badly with the attribute syntax, so an alternative that's not horrid:
>
>    (a, b...) = aggregate;
>
> Later,
> Brad

Interesting idea, I like it!