www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - RValue DIP Draft.

reply 12345swordy <alexanderheistermann gmail.com> writes:
Any issues that you have regarding the DIP can be posted here for 
the other 3 to look at and discuss with them.

Until then stop spamming the PR with commits please.

Link: https://github.com/dlang/DIPs/pull/218
Oct 18 2021
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 19 October 2021 at 00:28:47 UTC, 12345swordy wrote:

 Any issues that you have regarding the DIP can be posted here 
 for the other 3 to look at and discuss with them.

 Until then stop spamming the PR with commits please.

 Link: https://github.com/dlang/DIPs/pull/218


I've left a comment in that thread. But I'll repeat the gist of 
it here.

[As described in the review documentation][1], the Draft Review 
began the moment you submitted the DIP. Feedback on its current 
state is not spam. That is where comments on the DIP belong, not 
in this thread. The intent of Draft Review is to fix any obvious 
flaws that jump out at the people who care to participate.

You may not have been the original author of the DIP, but having 
submitted it, you are responsible for any revisions going 
forward. You're the Point of Contact, as described in [the 
authoring documentation][2]. That's not to say that you need to 
make actually make any changes yourself. If you don't intend to, 
then it's on you to coordinate with the original author(s) to 
address feedback, either by making changes or responding to 
review comments.

[1]: 
https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md#draft-review
[2] 
https://github.com/dlang/DIPs/blob/master/docs/process-authoring.md#step-1---determine-the-point-of-contact
Oct 18 2021
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 19 October 2021 at 01:44:02 UTC, Mike Parker wrote:

 On Tuesday, 19 October 2021 at 00:28:47 UTC, 12345swordy wrote:

 Any issues that you have regarding the DIP can be posted here 
 for the other 3 to look at and discuss with them.

 Until then stop spamming the PR with commits please.

 Link: https://github.com/dlang/DIPs/pull/218


 I've left a comment in that thread. But I'll repeat the gist of 
 it here.


Which I already made a response to it here:
https://github.com/dlang/DIPs/pull/218

-Alex
Oct 18 2021
prev sibling parent reply Elronnd <elronnd elronnd.net> writes:
I support this DIP.  However:


 For objects larger than 1-2 registers in size, passing by 
 pointer may be more efficent than passing by value


I don't buy this

Really, there are two issues being brought up:

1. Copying large objects is slow

2. Copy constructors may be slow

1 is exclusively an ABI issue, and should be solved at the ABI 
level (cf 
https://elronnd.net/writ/boring/2021-05-07_abi-wrong.html).

Regarding 2, consider that this DIP applies to rvalues.  That is, 
it applies to expressions like:

some_func(SomeStructWithAnExpensiveCopy())

The proper fix for this is to turn the last use of a struct into 
a move instead of a copy.  (I believe there was a DIP proposing 
this.)
Oct 18 2021
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 19 October 2021 at 03:53:45 UTC, Elronnd wrote:

 I support this DIP.  However:


While the DIP is in Draft Review, please leave all feedback in 
the PR thread.
Oct 18 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 19 October 2021 at 04:15:23 UTC, Mike Parker wrote:

 On Tuesday, 19 October 2021 at 03:53:45 UTC, Elronnd wrote:

 I support this DIP.  However:


 While the DIP is in Draft Review, please leave all feedback in 
 the PR thread.


Oops, didn't read this before replying, sorry.
Oct 18 2021
parent russhy <russhy gmail.com> writes:
On Tuesday, 19 October 2021 at 06:09:30 UTC, Tejas wrote:

 On Tuesday, 19 October 2021 at 04:15:23 UTC, Mike Parker wrote:

 On Tuesday, 19 October 2021 at 03:53:45 UTC, Elronnd wrote:

 I support this DIP.  However:


 While the DIP is in Draft Review, please leave all feedback in 
 the PR thread.


 Oops, didn't read this before replying, sorry.


This DIP is very welcome, i support this addition, i have been 
using the preview flag since a very long time, i would like to be 
finally supported out of the box!
Oct 19 2021
prev sibling parent Tejas <notrealemail gmail.com> writes:
On Tuesday, 19 October 2021 at 03:53:45 UTC, Elronnd wrote:

 I support this DIP.  However:


 For objects larger than 1-2 registers in size, passing by 
 pointer may be more efficent than passing by value


 I don't buy this

 Really, there are two issues being brought up:

 1. Copying large objects is slow

 2. Copy constructors may be slow

 1 is exclusively an ABI issue, and should be solved at the ABI 
 level (cf 
 https://elronnd.net/writ/boring/2021-05-07_abi-wrong.html).


Even `preview=in` subscribes to this philosophy and implements 
the same semantics, so idk if anyone will ever implement changes 
at ABI level.


 Regarding 2, consider that this DIP applies to rvalues.  That 
 is, it applies to expressions like:

 some_func(SomeStructWithAnExpensiveCopy())

 The proper fix for this is to turn the last use of a struct 
 into a move instead of a copy.  (I believe there was a DIP 
 proposing this.)


It was DIP 1040 that was introducing move constructors, 
moveAssign (and possiby rvalue references), but it's currently 
not being worked on :(
Oct 18 2021