Tuple DIP

[Timon Gehr]

On 14.01.2018 15:55, Q. Schroll wrote:
> On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
>> [...]
>> This DIP aims to make code like the following valid D:
>>
>> ---
>> auto (a, b) = (1, 2);
>> (int a, int b) = (1, 2);
>> ---
>> [...]
> 
> How is (1, 2) different from [1, 2] (static array)?

The first is a tuple, the second is a static array. This distinction 
exists already, it is not proposed in this DIP.

I.e., you could just as well ask "How is tuple(1, 2) different from [1, 
2] (static array)?". A (probably non-exhaustive) answer is that dynamic 
arrays have a 'ptr' property; slicing a static array will produce a 
dynamic array; tuples alias this to an 'expand' property that gives the 
components as an AliasSeq; an empty tuple will take up 1 byte of space 
in a struct/class, but an empty static array will not; empty static 
arrays have an element type, 'void' is allowed as the element type of an 
empty static array; array literals are _dynamic_ arrays by default, 
enforcing homogeneous element types, while tuple literals give you 
heterogeneous _tuples_, ...

None of this has much to do with the DIP though.

> It makes no sense to 
> me to have both and probably a bunch of conversion rules/functions.
> ...

The DIP proposes no new conversion rules, nor does it _introduce_ 
tuples. You'll need to complain about the status quo elsewhere; blaming 
the DIP for it makes no sense.

> Why don't you consider extending (type-homogeneous) static arrays to 
> (finite type enumerated) tuples?

Because tuples and arrays have significant differences as outlined above 
and tuple literal syntax is essentially useless if it needs to be 
accompanied by explicit type casts or annotations on every use. It's 
better to not add tuple syntax at all than to overload square brackets 
in this ad-hoc manner. Calling 'tuple(1, 2.0)' is less of a hassle than 
writing cast([int, double])[1, 2.0]. This is just not good language design.

> It solves
>   - 1-tuples

There is already a solution.

>   - comma operator vs. tuple literal

The comma operator is gone.

> instantly.

I think it introduces more problems than it solves.

> You'd have T[n] as an alias for the tuple type consisting of n objects 
> of type T.
> ...

So whether or not a tuple is instead a static array (according to the 
differences above) depends on whether or not the types happen to be 
homogeneous?

I do understand very well the superficial aesthetic appeal, but this is 
unfortunately just not a workable approach.

> I've written something about that here:
> https://forum.dlang.org/post/wwgwwepihklttnqghcaq@forum.dlang.org

(The DIP links to that thread.)

> (sorry for my bad English in that post)
> ...

The English is fine.

> The main reason I'd vote against the DIP: Parenthesis should only be 
> used for operator precedence and function calls.

You do realize that this translates to "just because"?
(That, and you forgot about template instantiation, type 
constructor/typeof application, if/for/while/switch/scope/... 
statements, type casts, basic type constructor/new calls, ... (list 
wildly non-exhaustive).)