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

[Luhrel]

 From the feedback thread:

On Friday, 8 January 2021 at 00:57:37 UTC, Q. Schroll wrote:
> The DIP massively fails to provide a good rationale why 
> std.array.staticArray is insufficient. It looks unpleasant, but 
> does the job in practically all cases demonstrated in the 
> examples a1 through a6.
>
> Example a1 currently doesn't work exactly because staticArray 
> returns immutable(char)[6], not char[6]. One needs a 
> char-specific function that is trivial to write:
>
>     C[n] staticCharArray(C, size_t n)(auto ref const(C)[n] 
> charArray)
>     {
>         return charArray;
>     }
>
> Then, example a1 can be written as:
>     auto a1 = "cerise".staticCharArray;
>     static assert(is(typeof(a1) == char[6]));
>
> Example a2 needs enum, but as long as someone knows what 
> they're doing, enum int[] is fine:
>     enum int[] d = [1, 2, 3]; // enum instead of const
>     auto a2 = d.staticArray;
>     static assert(is(typeof(a2) == int[3]));
>
> Example a3 is straightforward the primary use case for 
> staticArray:
>     auto a3 = [1,2,3].staticArray;
>
> Example a4 is, too.
>     auto a4 = [[1,2].staticArray, [3, 4]];
>     pragma(msg, typeof(a4)); // int[2][]


I really don't like the `.staticArray` because it's non-esthetic. 
I don't know if it's really argument, mainly because it's very 
personal.


>
> Example a5 is the first one that's actually painful to work 
> around:
>     enum a5DefaultValue = [1,2].staticArray;
>     void foo(typeof(a5DefaultValue) a5 = a5DefaultValue)
>     {
>         static assert(is(typeof(a5) == int[2]));
>     }
> I think this is rather an argument for allowing type deducted 
> defaulted function parameters generally, not only static arrays.
>

Good point.

> Example a6 is the prime use-case for auto type deduction:
>     int[2] bar() { return [1,2]; }
>     auto a6 = bar();
>     static assert(is(typeof(a6) == int[2]));
>

Correct. I'll rewrite this example.
There should be a type conversion:

```
int[2] bar() { return [1,2]; }
long[$] a6 = bar();  // implicit conversion
static assert(is(typeof(a6) == long[2]));
```

Now it makes more sense.

> 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. 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.

:scratching my head:

> B. The DIP says that int[2] and int[$] may end up the same 
> thing, but document different intent.

wtf. No ?

> 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.
> This is merely an example I came up with thinking for a minute.

The previous attempt was reverted because of control-flow 
analysis that was needed.

> There could be much better examples.

Yes.

> C. The DIP really must address the fact that what is gained is 
> very minor. Therefore, the difficulty of the implementation and 
> its maintenance in the compiler code plays a huge role.

I don't think, it's an old feature. Even BCPL had it.

> 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.

If I implement it, would people more agree with the DIP ?
For me it's a nonsense (and a waste of time, if the DIP is not 
accepted).