5 days ago

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

>

You mean like a system function which removes the scope-ness of an array? Let me introduce you to my other thread: https://forum.dlang.org/thread/t7qd45$1lrb$1@digitalmars.com

-Steve

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.

5 days ago

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

>

Sometimes algorithms require manipulation of structure, such as sorting arrays, or using linked lists, and sometimes it's nice to be able to point at things on the stack, temporarily. This is one of the things I was looking forward to with dip1000, since it does allow pointing at the stack when it can work out the details.

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
}
5 days ago

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

>

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

>

You mean like a system function which removes the scope-ness of an array? Let me introduce you to my other thread: https://forum.dlang.org/thread/t7qd45$1lrb$1@digitalmars.com

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.

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

5 days ago

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

>

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

>

Sometimes algorithms require manipulation of structure, such as sorting arrays, or using linked lists, and sometimes it's nice to be able to point at things on the stack, temporarily. This is one of the things I was looking forward to with dip1000, since it does allow pointing at the stack when it can work out the details.

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
}

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

5 days ago

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

>

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

>

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

>

You mean like a system function which removes the scope-ness of an array? Let me introduce you to my other thread: https://forum.dlang.org/thread/t7qd45$1lrb$1@digitalmars.com

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.

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

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.

4 days ago

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

>

On Tuesday, 21 June 2022 at 15:05:46 UTC, Mike Parker wrote:

Good article!

chinese version

3 days ago

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

>

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

>

On Tuesday, 21 June 2022 at 15:05:46 UTC, Mike Parker wrote:

Good article!

chinese version

Wow, thanks!

Next ›   Last »
1 2 3