January 08, 2021
On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote:
>
> ```
> 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 ?

It does not compile because length of `s` is not known at compile time. It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug!

I still think it deserves a mention -it's standard practice to put the "breaking changes" section even if there are none. In this case it seems a breaking change by the spec, but not by the implementation.
January 08, 2021
On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote:

> It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug!

Bugzilla: https://issues.dlang.org/show_bug.cgi?id=16213


January 08, 2021
On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote:
> On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote:
>> [...]
>
> It does not compile because length of `s` is not known at compile time. It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug!
>
> I still think it deserves a mention -it's standard practice to put the "breaking changes" section even if there are none. In this case it seems a breaking change by the spec, but not by the implementation.

Currently, isn't `$` only allowed inside the square brackets ?
https://dlang.org/spec/arrays.html#array-length

I don't think this bug is valid
January 08, 2021
On Friday, 8 January 2021 at 12:43:51 UTC, Luhrel wrote:
> On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote:
>> On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote:
>>> [...]
>>
>> It does not compile because length of `s` is not known at compile time. It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug!
>>
>> I still think it deserves a mention -it's standard practice to put the "breaking changes" section even if there are none. In this case it seems a breaking change by the spec, but not by the implementation.
>
> Currently, isn't `$` only allowed inside the square brackets ?
> https://dlang.org/spec/arrays.html#array-length
>
> I don't think this bug is valid

Yes, and it is inside square brackets - just not as the top-level expression. But no-one claimed it has to be top-level.
January 08, 2021
From the feedback thread:

On Friday, 8 January 2021 at 00:57:37 UTC, Q. Schroll wrote:
> The DIP massively fails to provide a good rationale why std.array.staticArray is insufficient. It looks unpleasant, but does the job in practically all cases demonstrated in the examples a1 through a6.
>
> Example a1 currently doesn't work exactly because staticArray returns immutable(char)[6], not char[6]. One needs a char-specific function that is trivial to write:
>
>     C[n] staticCharArray(C, size_t n)(auto ref const(C)[n] charArray)
>     {
>         return charArray;
>     }
>
> Then, example a1 can be written as:
>     auto a1 = "cerise".staticCharArray;
>     static assert(is(typeof(a1) == char[6]));
>
> Example a2 needs enum, but as long as someone knows what they're doing, enum int[] is fine:
>     enum int[] d = [1, 2, 3]; // enum instead of const
>     auto a2 = d.staticArray;
>     static assert(is(typeof(a2) == int[3]));
>
> Example a3 is straightforward the primary use case for staticArray:
>     auto a3 = [1,2,3].staticArray;
>
> Example a4 is, too.
>     auto a4 = [[1,2].staticArray, [3, 4]];
>     pragma(msg, typeof(a4)); // int[2][]


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.


>
> Example a5 is the first one that's actually painful to work around:
>     enum a5DefaultValue = [1,2].staticArray;
>     void foo(typeof(a5DefaultValue) a5 = a5DefaultValue)
>     {
>         static assert(is(typeof(a5) == int[2]));
>     }
> I think this is rather an argument for allowing type deducted defaulted function parameters generally, not only static arrays.
>

Good point.

> Example a6 is the prime use-case for auto type deduction:
>     int[2] bar() { return [1,2]; }
>     auto a6 = bar();
>     static assert(is(typeof(a6) == int[2]));
>

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

Now it makes more sense.

> This feature would have a reasonable chance of being accepted some years ago. Since this is the feedback thread, here's my constructive feedback:
>
> A. You maybe need better examples. Ease of reading and writing code can be an argument. You may want to state it somewhere. Unfortunately, this isn't a very good one. If you can come up with examples where workarounds are at least slightly more unpleasant than the one for Example a5 (that don't look too artificial), it might work out.

:scratching my head:

> B. The DIP says that int[2] and int[$] may end up the same thing, but document different intent.

wtf. No ?

> IMO, this is the best argument this DIP has. An immediate case where this is relevant is as a function return type. As an example, opSlice (as the lowering of the double-dots in xs[0 .. 1]) returns size_t[2].
> It won't ever return another number of size_t, so size_t[$] would be wrong conceptually. Other functions returning static arrays might return T[4], but the 4 isn't particular to the use case. If it might change, this can be documented using T[$] so that uses of the function don't rely on the 4 too much.
> This is merely an example I came up with thinking for a minute.

The previous attempt was reverted because of control-flow analysis that was needed.

> There could be much better examples.

Yes.

> C. The DIP really must address the fact that what is gained is very minor. Therefore, the difficulty of the implementation and its maintenance in the compiler code plays a huge role.

I don't think, it's an old feature. Even BCPL had it.

> If you can provide an implementation that most people would agree isn't that big of a deal having in the compiler, that would be really valuable.

If I implement it, would people more agree with the DIP ?
For me it's a nonsense (and a waste of time, if the DIP is not accepted).


January 08, 2021
On Friday, 8 January 2021 at 14:02:03 UTC, Dukc wrote:
> On Friday, 8 January 2021 at 12:43:51 UTC, Luhrel wrote:
>> [...]
>
> Yes, and it is inside square brackets - just not as the top-level expression. But no-one claimed it has to be top-level.

Well, it's not specified in the doc, but every example uses it as a top-level expression.

PS: It's a bit off-topic, but it may change my point of view.
January 11, 2021
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.

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.

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


January 11, 2021
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
>> ```
>> 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[]`

This is the error you get today if you write `long[2]` for the type of a6. (It's a bit confusing that `long[]` slice type is mentioned in the message).
January 11, 2021
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
> [snip]
>
> 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.
> [snip]

Could you provide an example? (apologies if you already have...)
January 11, 2021
On Monday, 11 January 2021 at 13:05:18 UTC, jmh530 wrote:
> On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
>> [snip]
>>
>> 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.
>> [snip]
>
> Could you provide an example? (apologies if you already have...)

Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal.