Jump to page: 1 2
Thread overview
DIP1000
Jun 23, 2022
ag0aep6g
Jun 23, 2022
ag0aep6g
Jun 24, 2022
Paul Backus
Jun 24, 2022
Dukc
Jun 24, 2022
Loara
Jun 28, 2022
Loara
Jun 29, 2022
bauss
Jun 30, 2022
Loara
Jul 02, 2022
Loara
June 23, 2022

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);
}

>

Error: scope variable b assigned to non-scope (*a).next

June 23, 2022

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

>

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);
}

>

Error: scope variable b assigned to non-scope (*a).next

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.

June 23, 2022

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?

>

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.

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

June 23, 2022

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

>

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?

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.

June 23, 2022

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

>

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.

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

June 23, 2022

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

>

It's a weird rule for sure.

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.

June 24, 2022

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

>

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

>

It's a weird rule for sure.

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.

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.

June 24, 2022

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

>

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

>

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

>

It's a weird rule for sure.

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.

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.

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.

June 24, 2022

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

>

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

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.

June 24, 2022

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

>

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

>

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

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.

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

« First   ‹ Prev
1 2