What about mandatory @system attribute? https://github.com/dlang/dmd/pull/5972#issuecomment-242227591

On Sunday, 16 October 2016 at 13:45:42 UTC, Dicebot wrote:
> So, there is a pull request (https://github.com/dlang/dmd/pull/5972)
> which is intended to implement DIP1000
> (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md).

Can we first get a high level overview about existing discussions and the goals/problems of DIP1000.
Not sure this forum is the right place for detailed DIP/PR reviews.

The DIP is named Scoped Pointers, but seems to address any escaping references (including classes).
Will it fully enable @safe reference counted memory management?
What pieces of the puzzle are still missing?
How much of DIP1000 does #5972 implement?

I read that RC `opAssign` and `destroy` would remain unsafe b/c destroying the owner might leave a dangling ref parameter in `fun(ref RCS rc, ref int ri)`.
It seems that unsafe assignment/destruction of RCs would be very limiting.
Do we at least have an idea how to tackle this problem? In the RCClass idea an additional addRef/decRef call was proposed.
Also see https://github.com/dlang/DIPs/pull/35#issuecomment-252345548.

On Sunday, 16 October 2016 at 13:45:42 UTC, Dicebot wrote:
> Problem is that Walter wants to prioritize moving on with it (which is reasonable) but the PR is too complicated to be reviewed by most other developers.

Just through with my first read of DIP1000.
First impressions interesting, incoherent, might or might not solve our problems.
Will give it some more time in the next few days.
But IMHO we should ensure that we have sound specs (backed by tests) that solve the __right__ use-cases before discussing implementations. As part of the implementation we'll have to transform this into a more easily understandable spec anyhow, so we might as well do that in the beginning.

On 10/19/2016 10:48 AM, Martin Nowak wrote:
> Can we first get a high level overview about existing discussions and the goals/problems of DIP1000.

Simply put, it provides the means to guarantee that a pointer supplied as a function argument does not escape the scope of that function. Special consideration is given to functions that return their arguments.


> The DIP is named Scoped Pointers, but seems to address any escaping references
> (including classes).

It includes classes, delegates, and dynamic arrays.


> Will it fully enable @safe reference counted memory management?

No, because an RC design also requires the preincrement as noted below.


> What pieces of the puzzle are still missing?

The preincrement thing, but that is not DIP1000.


> How much of DIP1000 does #5972 implement?

All.


> I read that RC `opAssign` and `destroy` would remain unsafe b/c destroying the
> owner might leave a dangling ref parameter in `fun(ref RCS rc, ref int ri)`.
> It seems that unsafe assignment/destruction of RCs would be very limiting.
> Do we at least have an idea how to tackle this problem? In the RCClass idea an
> additional addRef/decRef call was proposed.
> Also see https://github.com/dlang/DIPs/pull/35#issuecomment-252345548.

The solution to that has been proposed and forgotten a couple of times. It is to have the compiler insert code to preemptively increment the reference count, then reassigning the RC object will not invalidate references to its internals. This is beyond the scope of DIP1000, though. DIP1000 is necessary for memory safety even without reference counting.

On 10/19/2016 3:12 PM, Martin Nowak wrote:
> On Sunday, 16 October 2016 at 13:45:42 UTC, Dicebot wrote:
>> Problem is that Walter wants to prioritize moving on with it (which is
>> reasonable) but the PR is too complicated to be reviewed by most other
>> developers.
>
> Just through with my first read of DIP1000.
> First impressions interesting, incoherent, might or might not solve our problems.
> Will give it some more time in the next few days.
> But IMHO we should ensure that we have sound specs (backed by tests) that solve
> the __right__ use-cases before discussing implementations. As part of the
> implementation we'll have to transform this into a more easily understandable
> spec anyhow, so we might as well do that in the beginning.

I suggest looking over the test cases that come with the PR. They are straightforward. Whether they are the right use cases or not is debatable, but they each illustrate an existing safety hole in D today that the PR plugs.

On 10/16/2016 11:15 PM, Walter Bright wrote:
> On 10/16/2016 1:03 PM, Dicebot wrote:
>> Where does it come from?
> 
> It comes from trying to compile code with the new safety checks, and having it fail to compile and require adding annotations all over the place. The idea is to infer such annotations in the obvious places. 'return' was already successfully inferred in many places, this just extends an existing practice.
> 
> 
>> I don't see any mention of such deduction in https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
> 
> It's one of those things that becomes necessary once trying to implement it.

Walter, there is no way we can merge your PR if it implements things not mentioned in DIP. If you don't want to spend time adjusting it yourself, please, at least notify me about what has changed. That will save both of us a lot of time.

>> and it doesn't look like a good idea at all.
> 
> Inferring 'scope' and 'return' as much as possible makes @safe much more palatable. All I can say is try to break it!

It also makes reasoning about what your code does much harder, adding unacceptable amount of magic to it. I'd much prefer to rely on `auto` and fix rest of cases myself through deprecations than go with current "helpful" behavior.

Such semantics are also unprecedented in D as far as I can remember. Before storage classes would never be inferred for variables with explicit type. That is highly confusing.

Right now I think this is a bad decision and should be reconsidered. Would like to now what other developers thing though.

On 10/16/2016 10:51 PM, Walter Bright wrote:
> As for error [2], 'ref' is meant to be a restricted pointer. Converting a restricted pointer to a regular pointer, which is what &this does, undermines the whole point of having 'ref', and so is disallowed in @safe code.
> 
> Consider:
> 
>   @safe int* foo(return ref int r) {
>     return &r; // Error: cannot take address of parameter r in @safe
> function foo
>   }

This must not compile indeed. But this is perfectly fine:

@safe scope int* foo (return scope ref int r) {
    return &r; // taking address of r is fine because returned pointer
can't outlive the reference
}

As far as I can see right now, from the safety PoV scoped pointer is strictly equivalent to ref.

On 10/16/2016 10:30 PM, Walter Bright wrote:
> It works because 'scope' is inferred as a storage class when an expression that needs scope is used to initialize a local. y gets a subset of the life of instance. Doing such inference makes using -transition=safe far more palatable.
> 
> BTW, reducing the examples to their minimums helps a lot.

This compiles too:

```
int* x;

@safe unittest
{
    @safe static struct S
    {
        int data;

        int* borrow () return scope @trusted {
            return &this.data;
        }
    }

    S instance;
    x = instance.borrow();
}
```

Now, _this_ must be wrong, right?

On 10/20/2016 01:12 AM, Martin Nowak wrote:
> But IMHO we should ensure that we have sound specs (backed by tests) that solve the __right__ use-cases before discussing implementations. As part of the implementation we'll have to transform this into a more easily understandable spec anyhow, so we might as well do that in the beginning.

This is exactly what I am trying to do in this thread (which is continuation of e-mail exchange with Walter on same topic). Coming up with set of useful practical snippets based on proposed implementation and using them to figure out subtle semantical details.

Once I understand what is supposed to work and what is not, I'll give my try at complete rewrite of DIP1000 to make it more coherent with intentions.

On 10/20/2016 12:03 PM, Walter Bright wrote:
> I suggest looking over the test cases that come with the PR. They are straightforward. Whether they are the right use cases or not is debatable, but they each illustrate an existing safety hole in D today that the PR plugs.

If I was to judge by available test cases only, I would have decided DIP1000 is waste of time and brings nothing useful to the table. They are terrible in showing implementation goals being low level regression testing artifacts.

Really, do you think anyone will ever be impressed seeing code like `int* foo1(return scope int* p) { return p; }`? DIP1000 as defined can allow much more interesting things and tests should show that too, not just synthetic artifacts.