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

Nick Treleaven nick at geany.org
Wed Jan 6 18:22:32 UTC 2021


 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;}

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

The inferred return type is int[], and causes an error if the 
return type is specified as int[4].

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


More information about the Digitalmars-d-announce mailing list