www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP35: supplement to DIP25: Sealed References

reply "Zach the Mystic" <reachzach gggggmail.com> writes:
http://wiki.dlang.org/DIP35

I've talked about this before, but it seems like the right time 
to formalize it, especially to illustrate the slight conflict it 
would impose on using 'scope ref' to allow rvalue temporary 
references. If 'ref' itself were made completely safe using 
'scope' and/or 'out' return values, it would be possible to allow 
even rvalue temporaries to escape by returning from the function 
they were passed to. It may not in fact be a good programming 
practice, but that is a different design decision. If returning 
rvalue references were disallowed, it would therefore pose no 
threat to using 'scope ref', since 'scope' and 'scope ref' would 
be fully compatible then. (I'm not specifically in favor of 
'scope ref' to mean rvalue temporaries, but at least this 
compatibility issue is laid on the table. I don't think it's a 
horrible choice either, because it saves on syntax creep, but its 
meaning *is* confusing at first glance.)
Apr 06 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 7 April 2013 at 05:36:26 UTC, Zach the Mystic wrote:

 http://wiki.dlang.org/DIP35

 I've talked about this before, but it seems like the right time 
 to formalize it, especially to illustrate the slight conflict 
 it would impose on using 'scope ref' to allow rvalue temporary 
 references. If 'ref' itself were made completely safe using 
 'scope' and/or 'out' return values, it would be possible to 
 allow even rvalue temporaries to escape by returning from the 
 function they were passed to. It may not in fact be a good 
 programming practice, but that is a different design decision. 
 If returning rvalue references were disallowed, it would 
 therefore pose no threat to using 'scope ref', since 'scope' 
 and 'scope ref' would be fully compatible then. (I'm not 
 specifically in favor of 'scope ref' to mean rvalue 
 temporaries, but at least this compatibility issue is laid on 
 the table. I don't think it's a horrible choice either, because 
 it saves on syntax creep, but its meaning *is* confusing at 
 first glance.)


At this point, I'm not sure why we simply don't consider to 
introduce the concept of lifetime, rust style.
Apr 07 2013
prev sibling next sibling parent reply Robert <jfanatiker gmx.at> writes:
Hi!

I just read DIP35, sounds good as far as I can tell. What I missed, is
overloading rules, what function would be chosen if you have overloads
that take per value/auto ref/ref/scope ref/in ref for lvalues,
rvalues, ...

Best regards,
Robert
Apr 17 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Wednesday, 17 April 2013 at 13:49:23 UTC, Robert wrote:

 Hi!

 I just read DIP35, sounds good as far as I can tell. What I 
 missed, is
 overloading rules, what function would be chosen if you have 
 overloads
 that take per value/auto ref/ref/scope ref/in ref for lvalues,
 rvalues, ...

 Best regards,
 Robert



 Ooops, I meant I just read DIP36. Sorry for that, wrong thread.


Good point. I will add this as soon as possible.
If you understand the code, you can also take a look at the pull:
https://github.com/D-Programming-Language/dmd/pull/1903

But for other things we should switch to the correct thread:
http://forum.dlang.org/thread/ylebrhjnrrcajnvtthtt forum.dlang.org

;)
Apr 17 2013
parent reply "Diggory" <diggsey googlemail.com> writes:
I like this except for the proposed "addressOf" function from 
DIP25 which is massively overkill. The safe-ness of & on a ref 
should be determined by the compiler, so that initially it could 
be unsafe but that could be relaxed when the compiler can 
determine that the pointer does not escape. Syntactic ambiguities 
with properties can be resolve several other ways that are 
simpler and clearer.

Anyway the main point I had was that everyone seems to be 
assuming that returning R-value references from a function is 
bad. (The ONLY effect "scope ref" has in DIP36, above and beyond 
"ref", is preventing the parameter being returned)

The fact is with DIP35 alone there is no way returning R-value 
references can cause unsafe-ness:

int getRValue() { return 1; }
ref int forward(ref int p) { return p; }
void other(ref int p) { /* does something interesting with p */ }

other(forward(getRValue())) // Safe because other can't leak 
reference

int* ptr = &(forward(getRValue())) // Would fail at compile time 
because "forward" is marked "ref" rather than "out" so compiler 
can tell that return value could be an R value reference.

forward(getRValue()) = 1 // Compiler would at least produce a 
warning because it can see that this code is assigning to 
something that could be an R-value reference. This is not unsafe 
just not useful.

So basically if this is implemented as suggested there is no need 
for special treatment of R-values, which is good!
Apr 22 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 22 April 2013 at 17:01:43 UTC, Diggory wrote:

 I like this except for the proposed "addressOf" function from 
 DIP25 which is massively overkill. The safe-ness of & on a ref 
 should be determined by the compiler, so that initially it 
 could be unsafe but that could be relaxed when the compiler can 
 determine that the pointer does not escape. Syntactic 
 ambiguities with properties can be resolve several other ways 
 that are simpler and clearer.

 Anyway the main point I had was that everyone seems to be 
 assuming that returning R-value references from a function is 
 bad. (The ONLY effect "scope ref" has in DIP36, above and 
 beyond "ref", is preventing the parameter being returned)

 The fact is with DIP35 alone there is no way returning R-value 
 references can cause unsafe-ness:

 int getRValue() { return 1; }
 ref int forward(ref int p) { return p; }
 void other(ref int p) { /* does something interesting with p */ 
 }

 other(forward(getRValue())) // Safe because other can't leak 
 reference

 int* ptr = &(forward(getRValue())) // Would fail at compile 
 time because "forward" is marked "ref" rather than "out" so 
 compiler can tell that return value could be an R value 
 reference.

 forward(getRValue()) = 1 // Compiler would at least produce a 
 warning because it can see that this code is assigning to 
 something that could be an R-value reference. This is not 
 unsafe just not useful.

 So basically if this is implemented as suggested there is no 
 need for special treatment of R-values, which is good!


'scope ref' would allow, that both, lvalues AND rvalues can be 
bound to. DIP 35 don't say anything about that.
Just to be clear:
The primary reason at all DIP 36 was created, was in general to 
find a possibility that accept rvalues ​​AND lvalues. That was 
the initial reason.
Apr 22 2013
parent "Diggory" <diggsey googlemail.com> writes:
 'scope ref' would allow, that both, lvalues AND rvalues can be 
 bound to. DIP 35 don't say anything about that.
 Just to be clear:
 The primary reason at all DIP 36 was created, was in general to 
 find a possibility that accept rvalues ​​AND lvalues. That was 
 the initial reason.


I understand that, and you said that the idea of rvalues being 
passed as "ref" had been rejected. What I want to know is why 
rvalues as "ref" are unacceptable while rvalues as "scope ref" 
are acceptable when both "ref" and "scope ref" would be exactly 
equivalent in every other way.
Apr 22 2013
prev sibling parent Robert <jfanatiker gmx.at> writes:
Ooops, I meant I just read DIP36. Sorry for that, wrong thread.

On Wed, 2013-04-17 at 15:49 +0200, Robert wrote:

 Hi!
 
 I just read DIP35, sounds good as far as I can tell. What I missed, is
 overloading rules, what function would be chosen if you have overloads
 that take per value/auto ref/ref/scope ref/in ref for lvalues,
 rvalues, ...
 
 Best regards,
 Robert
Apr 17 2013