On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
> On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote:
>>> Example a3 is straightforward the primary use case for staticArray:
>>>     auto a3 = [1,2,3].staticArray;
>>
>> I really don't like the `.staticArray` because it's non-esthetic. I don't know if it's really argument, mainly because it's very personal.
>
> The worst thing about it is you have to import std.array, so probably people won't bother scrolling to the top to add the import and losing/bookmarking their place, and will just count the items themselves. When it was originally proposed, it was in object.d.

Yep, I introduced this DIP because I had to count the number of elements in my array (I'm lazy).

>
> I think if the DIP proposed a literal syntax instead of a new variable declaration syntax, it would be much less of a burden to the compiler. I think we don't have any partial (variable) type inference syntax ATM.

I don't think that will be complicated to implement, the compiler already says "mismatched array lengths, 2 and 1".

>
>> Correct. I'll rewrite this example.
>> There should be a type conversion:
>>
>> ```
>> int[2] bar() { return [1,2]; }
>> long[$] a6 = bar();  // implicit conversion
>> static assert(is(typeof(a6) == long[2]));
>> ```
>
> Error: cannot implicitly convert expression `bar()` of type `int[2]` to `long[]`

Meh, gonna review my examples.


```
int[] bar() { return [1,2]; }
int[$] a6 = bar();  // conversion from int[] to int[2]
static assert(is(typeof(a6) == int[2]));
```
When manually replacing $ by 2, it now works as excepted.

On Monday, 11 January 2021 at 20:25:14 UTC, Luhrel wrote:
>
> Meh, gonna review my examples.
>
>
> ```
> int[] bar() { return [1,2]; }
> int[$] a6 = bar();  // conversion from int[] to int[2]
> static assert(is(typeof(a6) == int[2]));
> ```
> When manually replacing $ by 2, it now works as excepted.

In fact, this shouldn't work with my DIP. It's too much work for the compiler.

On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote:
> [snip]
>
> Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal.

Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$).

Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an @nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested. The next best alternative is something like `enum immutable x = [1];` and then using `x`. Building that static array literal functionality into the compiler would be useful in that case.

On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
> Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an @nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested.

I've used std.array.staticArray for @nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`.

On Monday, 11 January 2021 at 21:33:36 UTC, Paul Backus wrote:
> On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
>> Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an @nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested.
>
> I've used std.array.staticArray for @nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`.

I know it can be used. My main point was "where the author is trying to limit calls to functions that aren't really central to what is being tested".

Consider

@nogc unittest
{
    assert([1, 2]s.nogcFunction == value);
}

vs

@nogc unittest
{
    import std.array: staticArray;
    assert([1, 2].staticArray.nogcFunction == value);
}

Not really different enough for me to care all that much, but the first one avoids the import and is a bit simpler.

I didn't really feel that strongly about the DIP. My comment was more that if that literal syntax were adopted, I would use it. There's a lot of literals that I rarely make use of and have to look up what it is. If I see 1.05L, I'm like "how could that be a long?" Until I look it up and find out it's a real literal. However, I imagine that people out there do make use of these things (maybe not for reals so much, given the hate a lot of people give them, but other ones).

On Monday, 11 January 2021 at 22:28:04 UTC, jmh530 wrote:
> On Monday, 11 January 2021 at 21:33:36 UTC, Paul Backus wrote:
>> On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
>>> Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an @nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested.
>>
>> I've used std.array.staticArray for @nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`.
>
> I know it can be used. My main point was "where the author is trying to limit calls to functions that aren't really central to what is being tested".

Yes, and my point is, staticArray is a well-tested standard-library function with an extremely simple implementation, so the odds of it introducing spurious faults into a unit test are essentially zero. So even though I always try to limit calls to unrelated functions in my unit tests, I consider staticArray safe to use.

On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
> On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote:
>> [snip]
>>
>> Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal.
>
> Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$).

You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)

On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote:
> On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
>> On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote:
>>> [snip]
>>>
>>> Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal.
>>
>> Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$).
>
> You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)

Interesting approach! However, it doesn't really resolve my underlying issue, which was that I would still need to import that s struct.

On Tuesday, 12 January 2021 at 18:19:14 UTC, jmh530 wrote:
> On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote:
>> On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
>>> On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote:
>>>> [snip]
>>>>
>>>> Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal.
>>>
>>> Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$).
>>
>> You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)
>
> Interesting approach! However, it doesn't really resolve my underlying issue, which was that I would still need to import that s struct.

To play the devil's advocate, it shouldn't be hard to change the compiler config file to auto-import any module of your choice (it config file would simply append it to the compiler command line).

That said, for me the unnecessary template instances generated for each different type and array length is a bigger reason for me preferring this DIP proposal, over the library approach.

On Tuesday, 12 January 2021 at 19:27:31 UTC, Petar Kirov [ZombineDev] wrote:
> [snip]
>
> To play the devil's advocate, it shouldn't be hard to change the compiler config file to auto-import any module of your choice (it config file would simply append it to the compiler command line).
>
> [snip]

That sounds a bit like magic, in the Arthur C. Clarke sense. Would that work in a project that other people are working on? (i.e., do they have to modify their compiler config files too?). I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves.