On Wednesday, 6 January 2021 at 19:04:14 UTC, jmh530 wrote:
> On Wednesday, 6 January 2021 at 18:34:31 UTC, Nick Treleaven wrote:
>> [...]
>
> What about something like below to handle any user-defined type.
>
> import std.stdio: writeln;
>
> template staticArray(T) {
>     T[n] staticArray(ulong n) (auto ref T[n] a) {return a;}
>
>     T[n] staticArray(U, ulong n) (auto ref U[n] a)
>         if (!is(T == U))
>     {
>         T[n] output;
>         for(size_t i = 0; i < n; i++) {
>             output[i] = cast(T) a[i];
>         }
>         return output;
>     }
> }
>
> T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;}
>
> struct Foo {
>     float x;
>     T opCast(T)() {
>         return cast(T) x;
>     }
> }
>
> void main(){
>     auto a = [1,2,3].staticArray!float;
>     pragma(msg, typeof(a)); // float[3]
>     a.writeln();
>     [1,2,3].staticArray.writeln();
>
>     auto b = [1,2,3].staticArray!Foo;
>     b.writeln();
> }

This works fine, even in betterC mode with LDC.
Doesn't work with betterC with DMD (https://issues.dlang.org/show_bug.cgi?id=19946).

I still don't like the .staticArray, but I'll use it if this DIP isn't approved.

Maybe `[$]` can be a shortcut to .staticArray.

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.

On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote:
> I think that `int[$] a = [1, 2, 3]` is much more user-friendly.
> ```
> auto a = [1,2,3].staticArray!ubyte
> ```


But what prevents you from writing your own library solution that works like this?

auto ints = mkarray(1,2,3,4,5);
auto floats = mkarray(1.0f,2,3,4,5);

etc

On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote:
> I don't get it.
> 1. `y` should be a int[].
True - see my correction at the feedback theard.

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

If your DIP is implemented, what you say is true. But the point is that right now it means a different thing - a cast to static array of the length of `something` (in the full example), not to length of `[1,2,3]`. The point is that your DIP will silently change the behaviour of code like this.

I do agree that this is such a rare enough occurence that we might be best off just accepting it. But it needs to be mentioned in the DIP.

On Thursday, 7 January 2021 at 15:27:09 UTC, Dukc wrote:
> On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote:
>> 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])
>> ```
>
> If your DIP is implemented, what you say is true. But the point is that right now it means a different thing - a cast to static array of the length of `something` (in the full example), not to length of `[1,2,3]`. The point is that your DIP will silently change the behaviour of code like this.

I understand want do you mean, but we're currently unable to use the `$` operation from `something` inside a cast.

```
int staticArrFunc(int[6] a)
{
    return a[0];
}

void main()
{
    int[] s = [1, 2, 3, 4, 5, 6];
    int[] y = s[0 .. staticArrFunc(cast(int[$]) [1,2,3])];
    // Error: CTFE internal error: trying to access uninitialized var
}
```

Do you have a currently working example, that would potentially be broken by my DIP ?

>
> I do agree that this is such a rare enough occurence that we might be best off just accepting it. But it needs to be mentioned in the DIP.

I don't want a DIP that will break other people codes.

On 1/6/21 1:14 PM, Luhrel wrote:
> On Wednesday, 6 January 2021 at 17:59:57 UTC, Jacob Carlborg wrote:
>> On 2021-01-06 10:21, Mike Parker wrote:
>>> This is the discussion thread for the first round of Community Review of DIP 1039, "Static Arrays with Inferred Length":
>>>
>>> https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md 
>>>
>>
>> There's `staticArray` to solve this issue [1].
>>
>> [1] https://dlang.org/phobos/std_array.html#.staticArray
> 
> It works only for the `int` type and above (and other types as structs).
> 
> example with short:
> ---
> extern(C) void main()
> {
>      import std.array;
>      auto a = [0, 1].staticArray!short;  // error
> }
> ---
> 
> To fix that, I need to cast every element:
> ---
> extern(C) void main()
> {
>      import std.array;
>      auto a = [cast(short) 1, cast(short) 2].staticArray!short; // ok
> }
> ---

With a tweak, it's possible:

T[n] staticArray(T, size_t n)(T[n] val...) { return val; }

auto arr = staticArray!short(1, 2);

Though the syntax isn't as nice...

-Steve

On 1/6/21 4:21 AM, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1039, "Static Arrays with Inferred Length":
> 
> https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md 
> 
> 
> The review period will end at 11:59 PM ET on January 20, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
> 
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
> 
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
> 
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
> 
> And my blog post on the difference between the Discussion and Feedback threads:
> 
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
> 
> Please stay on topic here. I will delete posts that are completely off-topic.

Should this be on the announce forum?

-Steve

On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:
> https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md

A bit off topic: Would Kenji Hara still have been an active Dlang community member if his solution to DIP-1039 hadn't been reverted.

On Thursday, 7 January 2021 at 21:26:28 UTC, Steven Schveighoffer wrote:

>
> Should this be on the announce forum?
>

No it shouldn't. But by the time I realized it was, the discussion was well underway.

On Thursday, 7 January 2021 at 21:42:55 UTC, Per Nordlöw wrote:
> On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:
>> https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md
>
> A bit off topic: Would Kenji Hara still have been an active Dlang community member if his solution to DIP-1039 hadn't been reverted.

Please start a new thread for that and let's keep this one focused on this DIP. Thanks!