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.

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.

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.

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.

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.

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

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.

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.