www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Concern about the ref return argument and scope

reply "deadalnix" <deadalnix gmail.com> writes:
We are going to introduce 2 features that basically are 2 hacks 
working around the same problem : lifetime.

It may sound like any of these is useful and progress, and 
somehow it is, but that is going to create many feature for 
underpowered capabilities.

This is this kind of situation where simple and easy collide.

I'd suggest we get a proper lifetime management. For ref return, 
we can still make it safe by defining the lifetime of the ref 
return as the intersection of the lifetime of the ref parameters 
and call it a day. As far as I can tell, this cover the vast 
majority of cases.
Jan 27 2015
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 January 2015 at 14:57, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 We are going to introduce 2 features that basically are 2 hacks working
 around the same problem : lifetime.

 It may sound like any of these is useful and progress, and somehow it is,
 but that is going to create many feature for underpowered capabilities.

 This is this kind of situation where simple and easy collide.

 I'd suggest we get a proper lifetime management. For ref return, we can
 still make it safe by defining the lifetime of the ref return as the
 intersection of the lifetime of the ref parameters and call it a day. As far
 as I can tell, this cover the vast majority of cases.
Lifetime 'this' probably also needs to exist, for objects that return members by ref. I think this covers practically all useful cases. What problem cases remain? Returning a global by ref? I should think that can also be supported easily enough; return by ref without lifetime implies global lifetime, and the function would compile error when trying to return a local/member/argument that way. I agree with you. I'm completely unsatisfied with the current proposals, or 'plans', as I think they have been promoted.
Jan 27 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 28 January 2015 at 07:04:43 UTC, Manu wrote:
 Lifetime 'this' probably also needs to exist, for objects that 
 return
 members by ref.
Well, as far as I'm concerned, this is a parameter like another. There is just syntax sugar to pass it around implicitely.
 I think this covers practically all useful cases. What problem 
 cases
 remain? Returning a global by ref?
 I should think that can also be supported easily enough; return 
 by ref
 without lifetime implies global lifetime, and the function would
 compile error when trying to return a local/member/argument 
 that way.
global lifetime by default for ref return do not make any sense IMO. It is very uncommon to return a ref to something you just allocated on the GC (why don't you return it directly ?) or to a static. If we can make lifetime explicit, I see no reason not to add a way to specify infinite lifetime.
 I agree with you. I'm completely unsatisfied with the current
 proposals, or 'plans', as I think they have been promoted.
Yup, I'm afraid that once they are in the wild, it is gonna solve the problem short term, but only one aspect of it, and ultimately get in the way to a more general solution.
Jan 28 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2015 8:57 PM, deadalnix wrote:
 For ref return, we can still
 make it safe by defining the lifetime of the ref return as the intersection of
 the lifetime of the ref parameters and call it a day. As far as I can tell,
this
 cover the vast majority of cases.
The trouble with that is when you *do* need to return a ref that is unrelated to the ref parameters, there will be no way to do it.
Jan 27 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 28 January 2015 at 07:55:22 UTC, Walter Bright 
wrote:
 On 1/27/2015 8:57 PM, deadalnix wrote:
 For ref return, we can still
 make it safe by defining the lifetime of the ref return as the 
 intersection of
 the lifetime of the ref parameters and call it a day. As far 
 as I can tell, this
 cover the vast majority of cases.
The trouble with that is when you *do* need to return a ref that is unrelated to the ref parameters, there will be no way to do it.
True, but unless you are returning a ref to a static variable, it has to come from an explicit or an implicit argument. And the solution to this is not an ad hoc way to specify each useful lifetime we can think of, but have sensible defaults and a generic way to specify them when default fall short.
Jan 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2015 12:02 AM, deadalnix wrote:
 On Wednesday, 28 January 2015 at 07:55:22 UTC, Walter Bright wrote:
 On 1/27/2015 8:57 PM, deadalnix wrote:
 For ref return, we can still
 make it safe by defining the lifetime of the ref return as the intersection of
 the lifetime of the ref parameters and call it a day. As far as I can tell,
this
 cover the vast majority of cases.
The trouble with that is when you *do* need to return a ref that is unrelated to the ref parameters, there will be no way to do it.
True, but unless you are returning a ref to a static variable, it has to come from an explicit or an implicit argument.
Or a ref to a new'd object. Or a ref to what the ref parameter pointed to. (ref is not transitive)
 And the solution to this is not an ad hoc way to specify each useful lifetime
we
 can think of, but have sensible defaults and a generic way to specify them when
 default fall short.
I believe DIP25 has the most sensible default that results in the least disruption. Besides, it makes more sense to say: "I am returning this parameter" than: "I am not returning this parameter, or that one, or this other one, either" Of course, there is a bit of leap of faith in the "least disruption" thing, only some experience with the feature will tell for sure.
Jan 28 2015
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Of course, there is a bit of leap of faith in the "least 
 disruption" thing, only some experience with the feature will 
 tell for sure.
It's very OK to experiment. deadalnix could be right: a more general solution could be easer to learn and use for the programmers than the -dip25 & -dip69 solution. Bye, bearophile
Jan 28 2015
prev sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Wednesday, 28 January 2015 at 08:32:33 UTC, Walter Bright 
wrote:
 On 1/28/2015 12:02 AM, deadalnix wrote:
 On Wednesday, 28 January 2015 at 07:55:22 UTC, Walter Bright 
 wrote:
 On 1/27/2015 8:57 PM, deadalnix wrote:
 For ref return, we can still
 make it safe by defining the lifetime of the ref return as 
 the intersection of
 the lifetime of the ref parameters and call it a day. As far 
 as I can tell, this
 cover the vast majority of cases.
The trouble with that is when you *do* need to return a ref that is unrelated to the ref parameters, there will be no way to do it.
True, but unless you are returning a ref to a static variable, it has to come from an explicit or an implicit argument.
Or a ref to a new'd object. Or a ref to what the ref parameter pointed to. (ref is not transitive)
 And the solution to this is not an ad hoc way to specify each 
 useful lifetime we
 can think of, but have sensible defaults and a generic way to 
 specify them when
 default fall short.
I believe DIP25 has the most sensible default that results in the least disruption. Besides, it makes more sense to say: "I am returning this parameter" than: "I am not returning this parameter, or that one, or this other one, either" Of course, there is a bit of leap of faith in the "least disruption" thing, only some experience with the feature will tell for sure.
I'm totally on board with this. In fact, to me 'ref' has nothing to do with it. If a parameter contains a pointer in safe code, you need to know what is done with it. I deliberately created DIP71 without 'ref' to illustrate my point: http://forum.dlang.org/post/xjhvpmjrlwhhgeqyoipv forum.dlang.org As far as disruption is concerned, my current philosophy is that all covariant attribute inference should be so thorough that you only have to add attributes if you *want* them, for your own personal purposes. You should never need them. I think the overall linking mechanism should be upgraded to allow reliable connections between the auto-generated `.di` files and the binaries they were generated for. `.di` files may be littered with attributes, but normal user code need not be. Unless you *want* them for code clarity purposes. I have no claim to know how this will actually play out. I won't pretend I know all the ins and outs of linking and `.di` file generation. But here's Dicebot's description of his forthcoming DIP on this matter: http://forum.dlang.org/post/otejdbgnhmyvbyaxatsk forum.dlang.org If the problem can be solved at the linking phase, inference can be assumed, no one will be burdened with marking their code involuntarily, and code can be completely safe. I still have to write an article on how I view reference safety. I haven't really thought about ownership, but I'm sure reference safety is an essential foundation for ownership.
Jan 28 2015