www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1022---foreach auto ref---Final Review

reply Mike Parker <aldacron gmail.com> writes:
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.
Nov 26 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 01 2019
next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Dec 01 2019
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Dec 01 2019
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
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.
Dec 04 2019
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
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 

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.
Dec 01 2019
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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 

 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.
Dec 01 2019
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
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.
Dec 04 2019
parent Mike Parker <aldacron gmail.com> writes:
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.
Dec 04 2019
prev sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
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...
Dec 05 2019