July 06
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"
July 06
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.
July 06

On Friday, 18 June 2021 at 17:00:14 UTC, Steven Schveighoffer wrote:

>

I strongly believe we should implement DIP1000 in an expressive manner, instead of relying on confusing conventions -- just make a type constructor to signify lifetime management and be done.

Yes, I'm thinking about that too. I wonder if there's a performance penalty for such an expressive management we are currently not paying for.

July 06
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.

July 06
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.
July 06
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.
July 06

On Tuesday, 6 July 2021 at 09:37:30 UTC, Walter Bright wrote:

>

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?

Here's an example:
https://forum.dlang.org/post/uxtqfrbomcsfzzbefkyw@forum.dlang.org

But such a function should not be the norm. The point is that users can simply add return and think "now I'm allowed to return this or &this.x or this.arr[0] or whatever" without delving into the whole "am I returning an address or value and am I allowed to" conundrum.

>

We could trick the code into doing that, but that would introduce all kinds of bugs into the lifetime analysis code.

Do you have an example?

>

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.

Awesome!

Next ›   Last »
1 2 3 4