Feedback Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1

[Luhrel]

On Friday, 8 January 2021 at 00:57:37 UTC, Q. Schroll wrote:
> ...
>
> This feature would have a reasonable chance of being accepted 
> some years ago. Since this is the feedback thread, here's my 
> constructive feedback:
>
> A. You maybe need better examples.

I agree with that.

> Ease of reading and writing code can be an argument. You may 
> want to state it somewhere.
> Unfortunately, this isn't a very good one. If you can come up 
> with examples where workarounds are at least slightly more 
> unpleasant than the one for Example a5 (that don't look too 
> artificial), it might work out.

I agree.

> B. The DIP says that int[2] and int[$] may end up the same 
> thing, but document different intent. IMO, this is the best
> argument this DIP has. An immediate case where this is relevant 
> is as a function return type. As an example, opSlice (as the 
> lowering of the double-dots in xs[0 .. 1]) returns size_t[2].
> It won't ever return another number of size_t, so size_t[$] 
> would be wrong conceptually. Other functions returning static 
> arrays might return T[4], but the 4 isn't particular to the use 
> case. If it might change, this can be documented using T[$] so 
> that uses of the function don't rely on the 4 too much.

I don't agree because the previous DIP was reverted because of 
the partial deduction needed for the functions. As xs[0 ..  1] 
returns a slice, it will be easier to cast it to a size_t[2] and 
then changing the return type to `auto`.

> C. The DIP really must address the fact that what is gained is 
> very minor.

Meh.

> Therefore, the difficulty of the implementation and its 
> maintenance in the compiler code plays a huge role. If you can 
> provide an implementation that most people would agree isn't 
> that big of a deal having in the compiler, that would be really 
> valuable.

I agree.