On Tuesday, 6 July 2021 at 05:15:24 UTC, Walter Bright wrote:
> On 7/5/2021 4:36 AM, claptrap wrote:
>> How the heck are us mere mortals supposed to use this stuff if you struggle to understand what it means?
>
> I make mistakes all the time. That's why D has unit tests built in, and an acceptance test suite.

It wasnt a criticism of you, it was like if the most experienced and talented developers are struggling to make sense of it how can the average programmer (me) ever hope to use it correctly.

It just seems that whenever a DIP1000/safe thread comes up nobody really understands it.

Like it's the exact antithesis of "easy to use correctly"

On Tuesday, 6 July 2021 at 05:15:24 UTC, Walter Bright wrote:
> This rule is arbitrary, precluding things like creating a `return ref` and
> `return scope` for the same parameter.

My question is: why? Why can't we allow a ref parameter to return either its address or its value? Given that lifetime(address) <= lifetime(value) and the returned value has lifetime(address), I'm struggling to see where it goes wrong.

On Tuesday, 6 July 2021 at 09:06:47 UTC, claptrap wrote:
> It wasnt a criticism of you, it was like if the most experienced and talented developers are struggling to make sense of it how can the average programmer (me) ever hope to use it correctly.

It is also a question of whether one wants to support people who use the language occasionally or only want to support full time users.

Languages like Ada and C++ is is the full time camp, but that only works if you have high commercial adoption, so not a good strategy in general.

Added PRs:

https://github.com/dlang/dmd/pull/12817
https://github.com/dlang/dmd/pull/12819

This, of course, breaks:

 struct Vector {
    float[] _elements;
    ref float opIndex(size_t i) scope return {
        return this._elements[i];
    }
 }

as Dennis points out. It still is the correct fix, however, we just have to find a way to get opIndex to work.

On 7/6/2021 2:23 AM, Dennis wrote:
> On Tuesday, 6 July 2021 at 05:15:24 UTC, Walter Bright wrote:
>> This rule is arbitrary, precluding things like creating a `return ref` and
>> `return scope` for the same parameter.
> 
> My question is: why? Why can't we allow a ref parameter to return either its address or its value? Given that lifetime(address) <= lifetime(value) and the returned value has lifetime(address), I'm struggling to see where it goes wrong.

It doesn't make sense to return either p or the address of p with the same function. What kind of a function does that? We could trick the code into doing that, but that would introduce all kinds of bugs into the lifetime analysis code.

The real problem is not being able to return the value of p as a ref, if p is also passed by ref.

I'm going to look into addressing that.