DIP19: Remove comma operator from D and provision better syntactic support for tuples

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Sep 25 14:03:37 PDT 2012


On 9/25/12 4:37 PM, deadalnix wrote:
> Le 25/09/2012 17:08, Andrei Alexandrescu a écrit :
>> On 9/25/12 10:05 AM, deadalnix wrote:
>>> OK, my bad. It means that tuple(...) behave differently than T...
>>> defined tuples.
>>>
>>> And both behave differently than Caml or Haskell's tuples.
>>>
>>> isn't the time for some unification ? Preferably on how tuples work in
>>> other languages, except if limitations can be shown and better proposal
>>> are made (and not include that in D2.xxx).
>>
>> I'm not sure actually. The way I look at it, built-in tuples are quite
>> low-level (types can't be spelled, automatic expansion and flattening,
>> undecided first-class semantics) and should seldom be dealt with
>> directly. The best use of built-in tuples is in the implementation of
>> truly well-behaved, composable tuples.
>>
>> Andrei
>
> We currently have 2 type of tuples, both unsatisfying it its own way
> (and I assume I can say it is confusing as I was confused before).
>
> If the new tuple stuff is implemented, D will ends up with 3 tuples
> systems, 2 of them unsatisfying and 1 of them satisfying (at least that
> is the goal).
>
> Still, language complexity would have increased in the process and have
> 3 time the same feature with different flavor isn't a good thing. Even
> if the tuple solution is a good one, the resulting situation isn't.

I agree. That's why I want to take the minimum amount of steps to make 
library tuples work. That minimum amount may be 1, i.e. just implement 
deconstruction.

Andrei


More information about the Digitalmars-d mailing list