DIP 1022, "foreach auto ref", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.

Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

The current revision of the DIP for this review is located here:

https://github.com/dlang/DIPs/blob/784386bc7d5adb023b160039ab1d4728e81ad62b/DIPs/DIP1022.md

In it, you'll find a link to and summary of the previous review rounds. This round of review will continue until 11:59 pm ET on December 10 unless I call it off before then.

Thanks in advance for your participation.

We are working on a comprehensive solution to the copy, move, and forward problem with function parameters. This naturally leads into under what conditions are the foreach ranges copied, moved, or forwarded to the foreach variable?

I'm concerned that we seem to now have a mess over what ref actually means. There's:

a) pre- and post- DMD 2.088 behavior of ref in foreach (as noted in the DIP, but there's no reference to the DIP for that change).

b) `auto ref` for function parameters

c) `auto ref` for function return values

d) rvalues being promoted to `ref` for function parameters
https://gist.github.com/andralex/e5405a5d773f07f73196c05f8339435a
https://digitalmars.com/d/archives/digitalmars/D/Binding_rvalues_to_ref_parameters_redux_325087.html
Implementation: https://github.com/dlang/dmd/pull/9817

I suggest putting this on hold until we have a comprehensive solution to function parameter copying, moving, and forwarding so we don't have to re-do foreach yet again after this DIP.

On Sun, Dec 1, 2019 at 8:35 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> We are working on a comprehensive solution to the copy, move, and forward problem with function parameters. This naturally leads into under what conditions are the foreach ranges copied, moved, or forwarded to the foreach variable?
>
> I'm concerned that we seem to now have a mess over what ref actually means. There's:
>
> a) pre- and post- DMD 2.088 behavior of ref in foreach (as noted in the DIP, but
> there's no reference to the DIP for that change).
>
> b) `auto ref` for function parameters
>
> c) `auto ref` for function return values
>
> d) rvalues being promoted to `ref` for function parameters https://gist.github.com/andralex/e5405a5d773f07f73196c05f8339435a https://digitalmars.com/d/archives/digitalmars/D/Binding_rvalues_to_ref_parameters_redux_325087.html Implementation: https://github.com/dlang/dmd/pull/9817
>
> I suggest putting this on hold until we have a comprehensive solution to function parameter copying, moving, and forwarding so we don't have to re-do foreach yet again after this DIP.

I completely agree with this.

On Sunday, 1 December 2019 at 10:31:56 UTC, Walter Bright wrote:
> I suggest putting this on hold until we have a comprehensive solution to function parameter copying, moving, and forwarding so we don't have to re-do foreach yet again after this DIP.

Yeah, if you're going to change the semantics copy/ref/move-semantics elsewhere, that sounds the wisest thing to do. However, you're currently discussing/implementing those things behind the scenes (except for Manu's rvalue ref DIP, which's implementation switch is aknowledged in the paper, in alternative #1). Because of that I'll let you make the decision about the postponing in the formal assessment -I don't want to personally postpone anything based on future plans or decisions that I do not see myself.

On 12/1/2019 4:58 AM, Manu wrote:
> I completely agree with this.

Manu completely agreeing with me? Ah, it is a lovely day!

On 12/1/2019 12:08 PM, Dukc wrote:
> Yeah, if you're going to change the semantics copy/ref/move-semantics elsewhere, that sounds the wisest thing to do. However, you're currently discussing/implementing those things behind the scenes (except for Manu's rvalue ref DIP, which's implementation switch is aknowledged in the paper, in alternative #1). Because of that I'll let you make the decision about the postponing in the formal assessment -I don't want to personally postpone anything based on future plans or decisions that I do not see myself.

Myself and a couple others are writing a DIP. You'll see it and comment on it as part of the usual process for these things.

On Sunday, 1 December 2019 at 20:08:12 UTC, Dukc wrote:
>
> Because of that I'll let you make the decision about the postponing in the formal assessment -I don't want to personally postpone anything based on future plans or decisions that I do not see myself.

I was just informed that I can't do that -formal assement can only be done once. That means that in a way, Walter needs my permission to postpone the DIP, and I do not want to block that. I have requested the review to be aborted (no point in continuing, since Mike told me that final review will have to be redone after postponing in any case) and the DIP to be postponed.

I've marked the DIP as Postponed:

https://github.com/dlang/DIPs/blob/bdeb9ce254f2ff695afeb20a072633148d177166/DIPs/other/DIP1022.md

And so that there are no misunderstandings for anyone following the thread, Walter doesn't need permission to Postpone the DIP. We could have completed the Final Review, sent it to him and Atila, and they could have said, "Let's wait". But they also could have rejected it outright. Not saying they would have, but they could have. The whole point of postponing it now is that we freeze the process in its tracks and avoid sending it for a final verdict for now. It's best to have the DIP author's consent, though.

Postponed DIPs may be revived at any time. Given that some time will have elapsed, it's a good idea to pick up the interrupted review again to make sure it's on par with any language changes that came in the interim. In this case, since we're in the Final Review, we would only repeat that if there were no or minimal revisions to the DIP. Otherwise, we'd either go back to the Community Review round or, if a complete rewrite were necessary, possibly terminate the DIP and go back to the Draft Review with a new one.

On Sunday, 1 December 2019 at 12:58:53 UTC, Manu wrote:
> On Sun, Dec 1, 2019 at 8:35 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> [...]
>
> I completely agree with this.

Same here, given the work that's being done right now.

On Sunday, 1 December 2019 at 10:31:56 UTC, Walter Bright wrote:
> We are working on a comprehensive solution to the copy, move, and forward problem with function parameters. This naturally leads into under what conditions are the foreach ranges copied, moved, or forwarded to the foreach variable?
>
> [...]

I think the language would actually be alot simpler if there was no "ref".  But I think that ship sailed a long time ago...