On 9/16/2019 9:47 AM, Olivier FAURE wrote:
> Sincere question: do you want people to experiment with it? If so, in what way? People have already come up with holes in your proposal, and you've essentially said that you didn't mind them; so what would people confirming that these holes still exist in the preview implementation change?

It's not a complete solution. That'll be for the @live proposal. But it does solve the more immediate problem of unsafety with refcounted objects.

On Monday, 16 September 2019 at 10:06:55 UTC, Walter Bright wrote:
> DIP 1021 can be experimented with as the code is now in the compiler and enabled with -preview=useDIP1021. I'd expect some trouble with it as it doesn't have much wear on the tires.

A few questions:

What would the default behaviour of the compiler be, is the ownership check on or off.
Can it be switched on/off by a compiler switch like now, in order to make existing code pass instead of adding @system or @trusted?
If an ownership problem is encountered, what is the action, compiler warning or error?

On Wednesday, 18 September 2019 at 07:38:49 UTC, Walter Bright wrote:
> It's not a complete solution. That'll be for the @live proposal. But it does solve the more immediate problem of unsafety with refcounted objects.

No it doesn't.

We've been over this, we've posted about 4 or 5 examples of ways refcounting safety could be broken in the previous thread, Exil already posted two examples in this thread.

So I'm going to ask again: why do you ask people to experiment with it if you're going to ignore the holes they find?

On 9/17/2019 8:54 AM, Exil wrote:
>      @safe:
> 
>      void foo(ref int, ref int) {
>      }
> 
>      void test() {
>          int[5] arr;
> 
>          // foo(arr[0], arr[0]); // error here
> 
>          foreach(size_t i, ref int a; arr) {
>              foo(a, arr[i]); // but ok here
>          }
>      }

That's a problem with the implementation, not the DIP.

On 9/17/2019 10:18 AM, Exil wrote:
> Another issue:
> 
>      @safe:
> 
> 
>      void foo(ref int, ref int) {
>      }
> 
>      void test() {
>          int b;
> 
>          int* a = &b;
>          int* c = &b;
> 
>          // foo( b, b); // error
> 
>          foo( *a, *c); // but this is ok
>      }

Yeah, that requires data flow analysis, which this DIP doesn't do. The @live one covers flow analysis.

On 9/18/2019 2:50 AM, Walter Bright wrote:
> That's a problem with the implementation, not the DIP.

I take that back, it's a data flow analysis issue. The DIP does not cover data flow analysis.

On 9/16/2019 11:23 AM, nkm1 wrote:
> The problem with this DIP is it a part of some bigger picture (which includes DIP1000, DIP25 and probably other stuff) and it seems no one understands what this bigger picture is.

The bigger picture is:

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/

The smaller picture is that one cannot create a ref counted objected that can safely expose a ref to its payload without this proposal.

On Wednesday, 18 September 2019 at 11:18:30 UTC, Walter Bright wrote:
> The smaller picture is that one cannot create a ref counted objected that can safely expose a ref to its payload without this proposal.

One cannot create a ref-counted object that can safely expose its payload *with* this proposal either.

eg:

    @safe:

    void foo(ref RefCounted rc, ref RefCounted rc2) {
        rc.reset();
        rc2.get() = 42;		// Whoops, memory corruption
    }

    void test() {
        RefCounted rc = someData();
        RefCounted* rc2 = &rc;

        foo( rc, *rc2 );
    }

Any proposal which doesn't have data flow analysis won't provide actual memory safety.

On Wednesday, 18 September 2019 at 11:14:01 UTC, Walter Bright wrote:
> On 9/18/2019 2:50 AM, Walter Bright wrote:
>> That's a problem with the implementation, not the DIP.
>
> I take that back, it's a data flow analysis issue. The DIP does not cover data flow analysis.

Which I am assuming you be creating a DIP that tackle the data flow analysis issue in the future right?

- Alex

On Wednesday, 18 September 2019 at 07:38:49 UTC, Walter Bright wrote:
> On 9/16/2019 9:47 AM, Olivier FAURE wrote:
>> Sincere question: do you want people to experiment with it? If so, in what way? People have already come up with holes in your proposal, and you've essentially said that you didn't mind them; so what would people confirming that these holes still exist in the preview implementation change?
>
> It's not a complete solution. That'll be for the @live proposal. But it does solve the more immediate problem of unsafety with refcounted objects.

Now the DIP makes sense, as to why it doesn't make sense. Because it's not complete. It solves no problem because of this, as someone else has showed. You can't review something that isn't complete as the author will just argue that any problems will be "fixed" in the future. There's nothing more to say... Yew haw cowboy!