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

[Luhrel]

On Wednesday, 6 January 2021 at 17:54:34 UTC, Dukc wrote:
> ...
>
> 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 don't agree.
As stated in the DIP, I didn't allowed because of the partial 
deduction.

>
> 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])];
>

As discussed in the community thread, `$` is only allowed between 
braces (as been reported as a bug, but I don't know if it is 
viable or not).

> ```
> 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]
> ```

It's a good idea, but then `int[5] a = [1,2,3];` should be 
allowed too (it's not the case rn). I may add those features in 
the DIP.