On 12/1/15 4:55 AM, Marc Schütz wrote:
> On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote:
>> * The one matter with the value/RefCounted approach is that RefCounted
>> cannot be made @safe.
>
> That's just as true for internal refcounting.

I don't think that's the case. The way I wrote code, safety can be achieved with a few controlled insertions of @trusted. -- Andrei

On Tuesday, 1 December 2015 at 14:15:47 UTC, Andrei Alexandrescu wrote:
> On 12/1/15 4:55 AM, Marc Schütz wrote:
>> On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote:
>>> * The one matter with the value/RefCounted approach is that RefCounted
>>> cannot be made @safe.
>>
>> That's just as true for internal refcounting.
>
> I don't think that's the case. The way I wrote code, safety can be achieved with a few controlled insertions of @trusted. -- Andrei

As long as you can pass the container and one of it's elements by mutable ref, it's unsafe (see the RCArray discussion [1]). If you can only access the elements by value (i.e. opIndex returns a copy), this precondition isn't fulfilled, but otherwise, I see no way to prevent it with the current language.

[1] http://forum.dlang.org/post/huspgmeupgobjubtsmfe@forum.dlang.org

On 12/01/2015 09:35 AM, Marc Schütz wrote:
> On Tuesday, 1 December 2015 at 14:15:47 UTC, Andrei Alexandrescu wrote:
>> On 12/1/15 4:55 AM, Marc Schütz wrote:
>>> On Monday, 30 November 2015 at 18:18:38 UTC, Andrei Alexandrescu wrote:
>>>> * The one matter with the value/RefCounted approach is that RefCounted
>>>> cannot be made @safe.
>>>
>>> That's just as true for internal refcounting.
>>
>> I don't think that's the case. The way I wrote code, safety can be
>> achieved with a few controlled insertions of @trusted. -- Andrei
>
> As long as you can pass the container and one of it's elements by
> mutable ref, it's unsafe (see the RCArray discussion [1]). If you can
> only access the elements by value (i.e. opIndex returns a copy), this
> precondition isn't fulfilled, but otherwise, I see no way to prevent it
> with the current language.
>
> [1] http://forum.dlang.org/post/huspgmeupgobjubtsmfe@forum.dlang.org

Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei

On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote:
> Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei

Disable owner when borrowing 'mutably', and not when borrowing 'constly'.

On Wednesday, 2 December 2015 at 06:45:33 UTC, deadalnix wrote:
> On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote:
>> Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei
>
> Disable owner when borrowing 'mutably', and not when borrowing 'constly'.

+1

On Wednesday, 2 December 2015 at 06:45:33 UTC, deadalnix wrote:
> On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote:
>> Ah, the good old assignment to reference. We need to prevent that from happening in safe code. Got any fresh ideas? -- Andrei
>
> Disable owner when borrowing 'mutably', and not when borrowing 'constly'.

Making it const is enough, it doesn't need to be disabled completely. (Except if you want to go full Rust with uniqueness etc.)

Maybe there's a way to relax it further. Not all modifications of the owner are necessarily bad... If we limit the restriction to types with indirections (or types with destructors?), and only apply it in @safe functions, this might not even break much code. I suspect that almost all @trusted code, and probably most @safe code, will already be written in a way that conforms to the new rules.

On 12/02/2015 01:45 AM, deadalnix wrote:
> On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote:
>> Ah, the good old assignment to reference. We need to prevent that from
>> happening in safe code. Got any fresh ideas? -- Andrei
>
> Disable owner when borrowing 'mutably', and not when borrowing 'constly'.

What does "disable owner" mean? Thx! -- Andrei

On Wednesday, 2 December 2015 at 15:58:19 UTC, Andrei Alexandrescu wrote:
> On 12/02/2015 01:45 AM, deadalnix wrote:
>> On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote:
>>> Ah, the good old assignment to reference. We need to prevent that from
>>> happening in safe code. Got any fresh ideas? -- Andrei
>>
>> Disable owner when borrowing 'mutably', and not when borrowing 'constly'.
>
> What does "disable owner" mean? Thx! -- Andrei

(He probably means: The owner is the object to which the reference points. Disabling means disallowing any access to it, at compile time.)

But your question gave me another idea: Instead of making the owner const, the compiler can insert calls to `owner.opFreeze()` and `owner.opThaw()` at the beginning/end of each borrowing, and leave the owner mutable. It's then up to the implementer to handle things in a way they like. For example, opFreeze() could just set a flag and assert that the underlying memory isn't freed during borrowing, or it could increment/decrement a reference count, or it could queue up any releases of the underlying storage to happen after the last borrow has expired (the idea you proposed as a solution for RCArray).

It's helpful in this case if the operators have the following signatures:

    T opFreeze();
    void opThaw(T cookie);

For the refcounting solution, opFreeze() can increment the refcount and return a pointer to it, and opThaw() can decrement it again. The methods need to be called each time a borrow starts/ends.

On Wednesday, 2 December 2015 at 15:58:19 UTC, Andrei Alexandrescu wrote:
> On 12/02/2015 01:45 AM, deadalnix wrote:
>> On Tuesday, 1 December 2015 at 17:27:20 UTC, Andrei Alexandrescu wrote:
>>> Ah, the good old assignment to reference. We need to prevent that from
>>> happening in safe code. Got any fresh ideas? -- Andrei
>>
>> Disable owner when borrowing 'mutably', and not when borrowing 'constly'.
>
> What does "disable owner" mean? Thx! -- Andrei

I mean you can't use it for the lifetime of the borrowing.