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

[Dukc]

On Wednesday, 6 January 2021 at 09:23:34 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review of DIP 1039, "Static Arrays with Inferred Length".

I'm slightly against this. The concept is sound per se, but I 
feel it might not pass the usefulness-to-weight ratio. 
`std.array.staticArray` can already handle most of the problems 
described, and it does work in betterC - I just tested with LDC 
1.20.1 targeting WebAssembly. while there are remaining cases 
(`auto fun(int[$] = [1,2,3])` isn't easy to represent now), I 
suspect they are a bit too trivial to justify a new feature.

On to refining the feature if it's accepted anyway. This should 
work:
```
int[$] bar(int[2] arr)              // Error: not allowed in 
functions declarations
{
     return arr ~ [3, 4];
}
```
Why? because you can use `auto` as return type. `Type[$]` should 
IMO work anywhere `auto` does. Of course this applies only if 
length of the returned array can be determined at compile time, 
as in this example.

I do agree that this should probably not work:
```
void bar(T)(T[$] a){}
```
...but I'd include the reasoning. That is, `auto a` would not be 
allowed either, and one can already achieve the same thing this 
way:
```
void bar(T, size_t TLen)(T[TLen] a){}
```

You need to mention that this DIP will break code in this, 
admittedly rare, case:
```
int[] x = something;
int y = something[0 .. staticArrFunc(cast(int[$])[1,2,3])];
```

I wonder if `$` should be allowed inside an expression, like this:
```
int[$+2] a = [1,2,3]; //static array of [1,2,3,0,0]
```