D needs a type expression syntax

[Timon Gehr]

On 08.05.23 13:21, Petar Kirov [ZombineDev] wrote:
> On Sunday, 7 May 2023 at 07:35:22 UTC, Timon Gehr wrote:
>> [..]
>>
>> Having `T[2]` be a tuple type `[T,T]` is one of those things that 
>> initially sound good enough on paper until you actually examine the 
>> existing array semantics that D already has and try to square them 
>> with tuple semantics. It does not work at all. D would need to break 
>> arrays. It's a pipe dream.
>>
> 
> Can you explain in more detail which parts of the language make the 
> unification impossible currently? Or to phrase the question differently, 
> in a hypothetical D3 language what (breaking) changes we would need to 
> do relative to D2 to make this possible?

I am not sure it is desirable if arrays are not all value types.

- If sliced, `T[n]` results in a `T[]`. Tuple slices should not decay 
into by-reference array slices randomly based on whether element types 
match. Also affects array assignment syntax and array operations.

- Type of array literals is `T[]` (uniform element type, dynamic length, 
reference type). It makes very little sense to have this and also have 
`[int, string]` be a tuple type.

- Tuple indices (presumably should) need to be statically known, array 
indices do not. Having `[T,S] t; e=t[i]` evaluate `i` at compile time 
iff `!is(T==S)` is potentially surprising behavior.

- `T[n]` has properties like `.ptr`, `dup`, `idup`. It seems a bit weird 
to provide this for tuples and it's not clear what they should do. I 
guess enabling them conditionally is an option, but that seems wacky.

- `void[n]` and `void[]`. How do they fit into the tuple story?