Walter Bright:

> How do you type an an array of pointers with different owners?

"Sound" doesn't mean it should be able to do everything. It will be just an approximated model. It means it's going to forbid some valid code, just like every type system. You use some @system code to work around some of those limitations. And if the design is good, such islands of unsafety are located inside Phobos constructs that leak (http://en.wikipedia.org/wiki/Leaky_abstraction ) very little.

Bye,
bearophile

On Wednesday, 4 March 2015 at 10:50:54 UTC, Walter Bright wrote:
> On 3/4/2015 1:16 AM, bearophile wrote:
>> Walter Bright:
>>> The complexity of a free list doesn't remotely compare to that of adding an
>>> ownership system.
>> A sound complete ownership system is the only good enough solution for D. That's
>> my opinion.
>
> How do you type an an array of pointers with different owners?
>

scope T*[] array;

> How do you deal with the combinatoric explosion of template instantiations with all those different ownership types?

There will be no combinatorial explosion. In our latest proposal (well, currently only in our minds), `scope` is a storage class, not a type modifier. For templates, which parameters are scope and which aren't depends only on the code inside the templates. There will be literally no additional instantiations because of different ownership.

I'm already halfway through the inference algorithm. I'm still looking for a way to formalize the detection of borrowing with aliasing (the problem started in the OP of this thread), in order to make those situations @system. I try to do it in a way that will also make deadalnix's "isolated islands" idea easy to implement later on.

I hope to finish writing up a proposal in the next days. Really, it is _much_ simpler than the previous one, and it will require almost no manual annotations.

On Wednesday, 4 March 2015 at 09:16:22 UTC, bearophile wrote:
> Walter Bright:
>
>> The complexity of a free list doesn't remotely compare to that of adding an ownership system.
>
> A sound complete ownership system is the only good enough solution for D. That's my opinion.
>
> Bye,
> bearophile

For that matters, I'd be happy with an unsound incomplete unsafe ownership system :)

scoped ownership feels "right", while RC and GC feel heavyweight.

On Wednesday, 4 March 2015 at 14:21:24 UTC, ponce wrote:
> For that matters, I'd be happy with an unsound incomplete unsafe ownership system :)

You already have that :^)

On Wednesday, 4 March 2015 at 10:50:54 UTC, Walter Bright wrote:
> On 3/4/2015 1:16 AM, bearophile wrote:
>> Walter Bright:
>>> The complexity of a free list doesn't remotely compare to that of adding an
>>> ownership system.
>> A sound complete ownership system is the only good enough solution for D. That's
>> my opinion.
>
> How do you type an an array of pointers with different owners?

You define a clear owner for everything so that this never happens.
That's what we do in C++ and shared_ptr is can be avoided as much as we like.

> How do you deal with the combinatoric explosion of template instantiations with all those different ownership types?

What we do in C++: with unsafety. Taking raw pointer in function parameters and function returns.

Mark in comments assumptions about which lifetime exceed what.

Modern C++ has no such combinatoric explosion. Instead of a std::vector of pointers, you know have a std::vector of std::uinque_ptr.

It still is quite easy, in the very least easier that doing deterministic destructon in D.

On 3/4/15 12:55 AM, Ivan Timokhin wrote:
> Excuse me if I miss something obvious, but:
>
>      void main()
>      {
>          auto arr = RCArray!int([0]);
>          foo(arr, arr[0]);
>      }
>
>      void foo(ref RCArray!int arr, ref int val)
>      {
>          {
>              auto copy = arr; //arr's (and copy's) reference counts are both 2
>              arr = RCArray!int([]); // There is another owner, so arr
>                                     // forgets about the old payload
>          } // Last owner of the array ('copy') gets destroyed and happily
>            // frees the payload.
>          val = 3; // Oops.
>      }

That's a problem, thanks very much for pointing it out. -- Andrei

On 3/4/15 2:03 AM, deadalnix wrote:
> A free list does not work as the data can be live. You cannot reuse it
> to maintain the free list.

Actually you can, which is a bit surprising. Consider:

RCArray!int arr;
arr.length = 10;
arr[5] = 42;
fun(arr, arr[5]);
...
void fun(ref RCArray!int a, ref int b) {
    assert(b == 42);
    a = a.init; // array goes to freelist
    a.length = 10; // array may reuse the previous one!
    assert(b == 42);
}

Now the interesting here thing is, the last assert should be allowed to fail. The code is still safe because there is no change of type, and the use of b after the array is gone is a bug in the application anyway because the parent structure is out of existence.

This makes code potentially tighter on memory usage but potentially more difficult to debug.


Andrei

On 3/4/15 6:02 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> I hope to finish writing up a proposal in the next days. Really, it is
> _much_ simpler than the previous one, and it will require almost no
> manual annotations.

Looking forward to it! -- Andrei

On 3/4/2015 6:27 AM, ponce wrote:
> You define a clear owner for everything so that this never happens.
> That's what we do in C++ and shared_ptr is can be avoided as much as we like.

C++ doesn't have ownership annotations and no checkable notion of a clear owner.

On Wednesday, 4 March 2015 at 17:06:53 UTC, Walter Bright wrote:
> On 3/4/2015 6:27 AM, ponce wrote:
>> You define a clear owner for everything so that this never happens.
>> That's what we do in C++ and shared_ptr is can be avoided as much as we like.
>
> C++ doesn't have ownership annotations and no checkable notion of a clear owner.

The standard library + type system provides mechanisms for clear ownership, but it does not check borrowing. Borrowing is potentially unsafe, and the programmer knows it, but it is not a big deal.