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/wwgwwepihklttnqgh...@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).)
