How am I supposed to write this:

import std;
@safe:

struct node {
    node* next;
}

auto connect(scope node* a, scope node* b)
{
    a.next = b;
}

void main()
{
    node x;
    node y;
    connect(&x,&y);
}

On Thursday, 23 June 2022 at 16:08:01 UTC, Ola Fosheim Grøstad wrote:

import std;
@safe:

struct node {
    node* next;
}

auto connect(scope node* a, scope node* b)
{
    a.next = b;
}

void main()
{
    node x;
    node y;
    connect(&x,&y);
}

DMD accepts this:

@safe:

struct node {
    node* next;
}

void connect(ref scope node a, return scope node* b)
{
    a.next = b;
}

void main()
{
    node y;
    scope node x;
    connect(x, &y);
}

But that only works for this very special case. It falls apart when you try to add a third node. As far as I understand, scope cannot handle linked lists. A scope pointer cannot point to another scope pointer.

So as to how you're supposed to do it: with @system.

On Thursday, 23 June 2022 at 19:38:12 UTC, ag0aep6g wrote:

void connect(ref scope node a, return scope node* b)

Thanks, so the return scope means «allow escape», not necessarily return?

One can do two levels, but not three. Got it. Works for some basic data-structures.

On Thursday, 23 June 2022 at 20:27:44 UTC, Ola Fosheim Grøstad wrote:

void connect(ref scope node a, return scope node* b)

It means "may be returned or copied to the first parameter" (https://dlang.org/spec/function.html#param-storage). You cannot escape via other parameters. It's a weird rule for sure.

On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:

Too complicated for what it does… Maybe @trusted isn't so bad after all.

On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:

Another slightly annoying thing is that it cares about destruction order when there are no destructors.

If there are no destructors the lifetime ought to be considered the same for variables in the same scope.

On Thursday, 23 June 2022 at 21:34:27 UTC, Ola Fosheim Grøstad wrote:

Having different lifetime rules for different types is worse UX than having the same lifetime rules for all types.

Imagine writing a generic function which passes all of your unit tests, and then fails when you try to use it in real code, because you forgot to test it with a type that has a destructor.

On Friday, 24 June 2022 at 03:03:52 UTC, Paul Backus wrote:

No, the lifetime is the same if there is no destructor. Being counter intuitive is poor usability.

If you want to help library authors you issue a warning for generic code only.

On Friday, 24 June 2022 at 05:11:13 UTC, Ola Fosheim Grøstad wrote:

It depends on whether you expect the rules to be smart or simple. Smart is not necessarily better, as the Unix philosophy tells you. I'm sure you have experience about programs that are unpredictable and thus frustating to use because they try to be too smart.

On Friday, 24 June 2022 at 09:08:25 UTC, Dukc wrote:

If this feature is meant to be used by application developers and not only library authors then it has to match their intuitive mental model of life times. I would expect all simple value types to have the same lifetime as the scope.

The other option is to somehow instill a mental model in all users that simple types like ints also having default destructors.

If it only is for library authors, then it is ok to deviate from "intuition".