Feedback Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1

[Luhrel]

On Wednesday, 6 January 2021 at 10:19:01 UTC, Basile B. wrote:
> On Wednesday, 6 January 2021 at 09:23:34 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community 
>> Review of DIP 1039, "Static Arrays with Inferred Length".
>
> I'd like to see a rationale for this restriction:
>
> ---
> int[$] bar(int[2] arr)              // Error: not allowed in 
> functions declarations
> {
>     return [3, 4];
> }
> ---
>
> as `int[$]` would be like `auto` but with a "hint" on how to 
> convert the result.
> It looks reasonable not to allow it, in a first time, however. 
> AFAIK dmd internal does not contain anything giving some hint 
> on the return type inferrence.

The previous `[$]` implementation was reverted due to the partial 
deduction.

Consider this:
---
int[$] bar(bool b)
{
     if (b)
         return [1, 2, 3];
     return [1, 2, 3, 4, 5, 6, 7, 8];
}
---
The compiler don't know, at compile time, if it needs to return a 
`int[3]` or a `int[8]`.
And I want to keep this feature simple to implement.

> Also if I trust the comment "not allowed in functions 
> declarations" then
>
> ---
> void bar(int[$] arr = [1,2]);
> ---
>
> would be rejected as this use case is like a variable 
> declaration with initializer so the dollar substitution at 
> compile-time is possible.

Well... my english is a bit rusty.
I wanted to say "not allowed as a return type".

I want to allow it at every variable declaration, like in C and 
C++.

>
> 1. Globally the examples are used to describe the semantics but 
> there is not enough of them. There should be a clear behavior 
> defined for each place where a type can be used. Why is this 
> allowed here, why not here.

Allowed only when declaring a variable with an affectation.

> 2. For now the DIP does not explain what was the problem with 
> the first attempt and how the new design addresses the problem 
> that lead the work to be reverted.

When I wrote this DIP, I didn't even knew that there were some 
previous attempts.

>
> To conclude, even if the change looks ok, the document lacks of 
> accuracy.

Reviews are made for that, aren't they ?