Is @safe still a work-in-progress?

[Atila Neves]

On Wednesday, 22 August 2018 at 09:05:13 UTC, Walter Bright wrote:
> On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
>> On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
>>> The problem is that the code we write doesn't deal directly 
>>> with pointers - see the recent confusion in this forum over 
>>> where `scope` on the left applies to the `this` pointer or 
>>> the one returned by the member function.
>>>
>>> Kagamin just told me I needed to use `return` instead of 
>>> `scope` to get things to work and I'm still not sure why.
>> 
>> The way I think about it is if you have a function that takes 
>> a pointer, any pointer, and either returns it or a pointer 
>> derived from it (dereferencing or indexing) that argument must 
>> be marked `return`. In your case it was a pointer derived from 
>> `this` so `return` must be applied to `this`.
>
>
> Another way to think about it is this:
>
>    S s;
>    return &s;
>
> We all know that is an error. The idea is to have a way to 
> express that for:
>
>     S s;
>     return s.foo();
>
> and:
>
>     S s;
>     return foo(&s);
>
> so that the compiler knows that the return value of foo() is 
> attached to the lifetime of s. Pretty much everything flows 
> from that.

Would the guideline below be correct?

"Add scope to every non-template member function that isn't meant 
to escape this and add return to every non-template member 
function that returns all or part of `this` by pointer or ref if 
you want the compiler to check that nothing gets escaped in @safe 
code."