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

[Luhrel]

On Wednesday, 6 January 2021 at 18:22:32 UTC, Nick Treleaven 
wrote:
> From the feedback thread:
>
> On Wednesday, 6 January 2021 at 17:54:34 UTC, Dukc wrote:
>> `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.
>
> Type inference for parameters with a default argument could be 
> made to work.
>
> auto fun(auto a = [1,2,3].staticArray) {return a;}
>

I think that `int[$] a = [1, 2, 3]` is much more user-friendly.
```
auto a = [1,2,3].staticArray!ubyte
```

is way too complicated than simply

```
ubyte[$] a = [1,2,3];
```

... but that's my opinion.

>> 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])];
>> ```
>
> Excellent point, but it isn't just casts, anywhere you use a 
> type (template instantiation) that is within an indexing 
> expression will have this problem.
>

I don't get it.
1. `y` should be a int[].
2. if staticArrFunc returns a size_t, then the problem can be 
simplified as:
```
staticArrFunc(cast(int[$])[1,2,3]); // no need to cast :
staticArrFunc([1,2,3]); // already works like that (if 
staticArrFunc takes a int[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]
>> ```
>
> Not worth it, easy to workaround.

I like this idea, even if there are workarounds.