On Thursday, 23 June 2022 at 00:37:24 UTC, Steven Schveighoffer wrote:

You are allowed to remove scope from an argument in unsafe code. It's only if you escape that argument when you trigger undefined behaviour. Just like you can cast away const, if you don't actually mutate the cast variable.

On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer wrote:

This works:

struct S
{
    int[] a;
    int[] get() return scope @safe { return a; }
    void set(return int[] b) return scope @safe
    { a=b; }
}

int[] f() @safe
{
    int[2] a;
    scope S t;
    int[] b=t.get;
    t.set=a;
    return b; //no
}

On 6/23/22 8:01 AM, Dukc wrote:

And what do you think a custom struct that circumvents the scopeness is going to do with that parameter?

To be clear, I think we're talking about something like:

struct ScopeArray(T)
{
   T[] arr;
   @system void opAssign(scope T[] param)
   {
      arr = param; // escaping scope
   }
}

-Steve

On 6/23/22 8:14 AM, Kagamin wrote:

struct S
{
     int[] a;
     int[] get() return scope @safe { return a; }
     void set(return int[] b) return scope @safe
     { a=b; }
}

int[] f() @safe
{
     int[2] a;
     scope S t;
     int[] b=t.get;
     t.set=a;
     return b; //no
}

This is just saying the same thing -- you must allocate your data on the stack in order to have scope elements assignable. This isn't always feasible.

    scope a = "first";
    scope b = "second";
    string[2] x = [a, b];
    auto arr = x[]; // ok
    arr = ["first", "second"]; // ok
    arr = [a, b]; // not ok

It's established that arr is attributed such that it's able to point at stack data. Fine.

It can also point at allocated data. Fine.

But the allocated data itself cannot point at scope data. This "somewhat" makes sense, because by the time the GC cleans up this array, the data is likely invalid (not in this case, but that's because we deliberately labeled non-scope data as scope).

However, you may need to mix both non-scope and scope data, which means you can't allocate on the stack. But there can be ways to mitigate this:

1. For this simple case, just allocate [a, b] on the stack. It's happening in other places (see my other thread), why not here?
2. The compiler could insert a call at the end of the scope to free the allocated data. It can't escape anyway, and freeing it early is part of the benefit of having scope. Or if it's determined that no destructors are involved, just let the GC clean it up.

The more cases where we make this painless for the user, the better.

-Steve

On Thursday, 23 June 2022 at 14:08:15 UTC, Steven Schveighoffer wrote:

struct ScopeArray(T)
{
   T[] arr;
   @system void opAssign(scope T[] param)
   {
      arr = param; // escaping scope
   }
}

By return scope. I'm not sure if it'd work with that opAssign example since we don't actually return the this pointer. I need to recheck what return scope means with void return type, before I write the next article - There is or at least was some rule regarding that situation.

But in any case you could accomplish the same with

@safe ScopeArray!T(T)(return scope T[] param)
{ return ScopeArray!T(param);
}

. Note that in this case you are not even trying to store scope variables as elements to an array, so we don't need @trusted.

On Wednesday, 22 June 2022 at 07:15:34 UTC, zjh wrote:

chinese version

On Saturday, 25 June 2022 at 02:03:01 UTC, zjh wrote:

Wow, thanks!