Tuple DIP

[Timothee Cour]

actually I just learned that indeed sizeof(typeof(tuple()))=1, but why
is that? (at least for std.typecons.tuple)
maybe worth mentioning that in the DIP (with rationale)

On Sun, Jan 14, 2018 at 8:18 AM, Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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).)