On Friday, 8 January 2021 at 00:57:37 UTC, Q. Schroll wrote:
> ...
>
> 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.

I agree with that.

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

I agree.

> B. The DIP says that int[2] and int[$] may end up the same thing, but document different intent. 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.

I don't agree because the previous DIP was reverted because of the partial deduction needed for the functions. As xs[0 ..  1] returns a slice, it will be easier to cast it to a size_t[2] and then changing the return type to `auto`.

> C. The DIP really must address the fact that what is gained is very minor.

Meh.

> Therefore, the difficulty of the implementation and its maintenance in the compiler code plays a huge role. 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.

I agree.

On Wednesday, 6 January 2021 at 17:54:34 UTC, Dukc wrote:
> ...
>
> 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. Of course this applies only if length of the returned array can be determined at compile time, as in this example.
>

I don't agree.
As stated in the DIP, I didn't allowed because of the partial deduction.

>
> I do agree that this should probably not work:
> ```
> void bar(T)(T[$] a){}
> ```
> ...but I'd include the reasoning. That is, `auto a` would not be allowed either, and one can already achieve the same thing this way:
> ```
> void bar(T, size_t TLen)(T[TLen] a){}
> ```
>
> 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])];
>

As discussed in the community thread, `$` is only allowed between braces (as been reported as a bug, but I don't know if it is viable or not).

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

It's a good idea, but then `int[5] a = [1,2,3];` should be allowed too (it's not the case rn). I may add those features in the DIP.