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.

On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:

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

The Feedback Thread is here:
https://forum.dlang.org/post/qglydztoqxhhcurvbxhs@forum.dlang.org

On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote:
> On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:
>
>>
>> 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.
>
> The Feedback Thread is here:
> https://forum.dlang.org/post/qglydztoqxhhcurvbxhs@forum.dlang.org

Before posting a review, I have a question:
What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ?

(nothing is explained here https://github.com/dlang/dmd/pull/4373)

On Wednesday, 6 January 2021 at 09:55:34 UTC, Basile B. wrote:
> On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote:
>> On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:
>>
>>> [...]
>>
>> The Feedback Thread is here:
>> https://forum.dlang.org/post/qglydztoqxhhcurvbxhs@forum.dlang.org
>
> Before posting a review, I have a question:
> What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ?
>
> (nothing is explained here https://github.com/dlang/dmd/pull/4373)

well never mind, I've mentioned in the review that nothing is explaiend about the old attempt.

I am in favour of more controlled type inference in general, but perhaps this one is a bit specific. What if you defined "_" to mean "deduce whatever should be in this spot", not only for static arrays, but for all types?


Then you could do:

int[_] = …

or

_[_] …


etc

On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad wrote:
> I am in favour of more controlled type inference in general, but perhaps this one is a bit specific. What if you defined "_" to mean "deduce whatever should be in this spot", not only for static arrays, but for all types?
>
>
> Then you could do:
>
> int[_] = …
>
> or
>
> _[_] …
>
>
> etc

'$' is not an ident char, that's why that works

On Wednesday, 6 January 2021 at 10:58:23 UTC, Basile B. wrote:
> '$' is not an ident char, that's why that works

Yeah, but "$" means length in D. I think it would be valuable to have more generic constraints than the DIP suggests so that it can be useful in multiple contexts.

Would appropriating "_" break a lot of code?

On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad wrote:
> int[_] = …
>
> or
>
> _[_] …

To expand on this with more examples, you might want to constrain "auto" in various ways with pattern matching:


// ensure static array of something with length 4

_[4] v = f();

// ensure that I get a MyContainer with some unspecified type elements

MyContainer<_> c = g();

// define a function that swaps the content of an array of length 2

void swap(ref _[2] a){ … }

// it would also be shorter than auto, but not sure if that is a good thing

_ x = 3  // same as "auto x = 3"

On Wednesday, 6 January 2021 at 11:11:41 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad wrote:
>> int[_] = …
>>
>> or
>>
>> _[_] …
>
> To expand on this with more examples, you might want to constrain "auto" in various ways with pattern matching:
>
>
> // ensure static array of something with length 4
>
> _[4] v = f();
>
> // ensure that I get a MyContainer with some unspecified type elements
>
> MyContainer<_> c = g();
>
> // define a function that swaps the content of an array of length 2
>
> void swap(ref _[2] a){ … }
>
> // it would also be shorter than auto, but not sure if that is a good thing
>
> _ x = 3  // same as "auto x = 3"

I thought about auto when reading the DIP too, but auto is more used like a Type (although being a storage class ;) ). It's never used to infer a value, i.e an expression. While I understand what you mean this is unrelated. Dollar is very well suited.

Maybe you could create the underscore-lang to showcase the idea ;)

On Wednesday, 6 January 2021 at 11:18:22 UTC, Basile B. wrote:
> I thought about auto when reading the DIP too, but auto is more used like a Type (although being a storage class ;) ). It's never used to infer a value, i.e an expression. While I understand what you mean this is unrelated. Dollar is very well suited.

Hmm...

My take is that this proposal is auto with a constraint, except it will also do implicit conversion.