auto arr = [1, 2, 3] should be a static array, not a GC allocated array

[Steven Schveighoffer]

On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:
> On Sunday, 17 July 2022 at 15:23:45 UTC, Steven Schveighoffer 
> wrote:
>> The second statement is much better, but you need the first to 
>> infer the length. Just specifying "infer the length" with a 
>> `[$]` on the type is a perfect fit.
>
> There may be ambiguity with `$` for length inside an 
> index/slice expression when an inferred static array type is 
> part of an expression:
> https://forum.dlang.org/post/qsjahatdiyxwojcwyedm@forum.dlang.org

It would not be ambiguous, as `int[$]` would refer to the new 
type.

I'm having a hard time believing that kind of expression is 
currently used anywhere.

it would be consistent with using $ inside an expression of 2 
nested arrays:

```d
int[] arr;
int[] foo;

return arr[0 .. foo[$-1]]; // does $ refer to arr.length or 
foo.length?
```

>
>> You also have an issue with const conversion that's not as 
>> easy to specify. e.g.:
>>
>> ```d
>> char[74] foo = "this is a long string that I don't want to 
>> have to count the characters in";
>> ```
>
> Presumably length inference would not include the terminating 
> nul byte of the string literal?

Of course, that's not actually included in the literal length. 
e.g. `"".length == 0`.

>
>> Can't use staticArray here because the type will be 
>> `immutable(char)[74]`.
>>
>> If I want to specify it should be char, I can't do 
>> `staticArray!char`, because then it doesn't infer anything.
>
> Could add an overload for that:
> https://forum.dlang.org/post/urzdeerfcvardyztxfab@forum.dlang.org

Fair point (if anything could someone create an issue on this so 
it's not forgotten?). But I still think the nested syntax isn't 
good.

>
>> This is a simple quality-of-life improvement. I think the 
>> original PR was reverted because it allowed too much 
>> inference, like:
>>
>> `auto[$] foo = [1,2,3,4];`
>>
>> I think just specifying the length is dependent on the length 
>> of the literal is enough benefit to justify the change. We 
>> don't need full inference of any static array type.
>
> Threads like these always use basic element types like int or 
> char. In practice the element type can be quite complex. It's a 
> pain to have to write out a complex type - e.g. 
> `typeof(x.map!(a => someExpr).front)`.

The use case for this escapes me. You can't do this with 
staticArray anyway.

```d
auto x = arr.map!(a => a * 2).array.staticArray; // error, can't 
pass Something[] to staticArray
```

So current code that might build such a thing isn't any worse off 
with the feature.

What you need to write for this use case is a complex 
voldemort-type-producing expression, and then make multiple calls 
to that thing, inside an array expression. I just don't see it 
being a thing.

> That could be solved by having specific syntax for static array 
> literals:
>
> ```d
> auto sa = $[1,2,3,4];
> ```

Maybe, maybe not. Yes, without a special syntax on the right 
side, you'd need a type for it, but I don't see a really 
convincing use case for this.

That being said, I would be *ok* with this syntax, or something 
that's identified on the expression. Hell, even if it was 
`__staticArray(expr)`, that would be at least a possible solution.

> That avoids supporting partial `auto` declarations (a reason 
> why Walter didn't like that PR).

That PR discussion is... interesting. I don't know exactly what 
the rejection was, aside from "this will just release the 
floodgates of crappy feature requests".

> It also allows inference when passing a literal to a template 
> function argument where the parameter is not already a static 
> array. The `$[]` syntax would literally mean "length array", 
> i.e. fixed length array.

I'm not opposed to it exactly. But it does suffer the same 
problems as `staticArray`. It is sometimes nice to use the 
left-hand-side of the construction/assignment to determine how 
the literal is interpreted.

> (Why do we overload the word 'static' here for arrays?)

I hate that they are called "static" arrays also. 
`fixedLengthArray` is probably not a great function name though.

>
> And it's prefix syntax, which would read well with your nested 
> static array example:
> ```d
> auto foo = $[$[1,2,3,4],[5,6,7,8]];
> ```
>
> It doesn't help your `char[$] foo = "immutable data";` case 
> though (which would need the staticArray overload or 
> equivalent).

Oh yeah, agreed. Maybe something can be done about that in the 
syntax, like `$char[...]` I don't know.

-Steve