DIP1000: Memory Safety in a Modern System Programming Language Pt.1

[Dukc]

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:
>
> ```d
> 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
```D
@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`.