Herb Sutter on zero cost exceptions for C++

[Timon Gehr]

On 27.09.19 18:40, H. S. Teoh wrote:
> On Fri, Sep 27, 2019 at 09:55:27AM +0000, Paulo Pinto via Digitalmars-d wrote:
>> On Friday, 27 September 2019 at 09:36:33 UTC, a11e99z wrote:
> [...]
>>> what is @life? (searching by forum gives only this message)
>>
>> https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
> 
> Thanks for the link! I've also been wondering, with all this talk about
> @live.
> 
> One comment on the article, though: ownership as defined by Walter seems
> unnecessarily restrictive, in that it's impossible to have multiple
> mutable pointers to an object.

Not impossible, you are just not supposed to do it. The proposal does 
zero checking at the @safe/@live interface, which means it's by 
convention. @live in the best case does nothing at all and in the worst 
case rips holes into @safe instead of closing them.

> Here's an enhancement based on an idea I
> had years ago: the concept of differentiating between "owning" pointers
> and "non-owning" pointers.
> ...

Yes, that's much better than a function attribute, but owning pointers 
don't need to be a built-in language concept. (See Rust.)

> An owning pointer is basically what Walter describes -- only a single
> such pointer can exist per object, and when that pointer goes out of the
> scope the object gets freed.  Allocation functions like malloc() return
> an owning pointer.  During its lifetime, however, any number of
> "non-owning" pointers can be made from it.
> ...

That's what's called borrowing in Rust, but you need to be careful.

> A "non-owning" pointer cannot be passed to free() (or equivalent).

Issue is you can have a non-owning pointer pointing to a data structure 
that contains owning pointers.

> In this scheme, free() only ever accepts an owning pointer.  Furthermore, a
> non-owning pointer cannot outlive the scope of the owning pointer: they
> are 'scope', and their scope must be statically provable to be a subset
> of the scope of the owning pointer they are borrowing from. There is no
> need to restrict them with regards to mutability, however.
> ...

Agreed.

> This system can be implemented using RAII: pointers returned from memory
> allocators like malloc() are wrapped in an OwnerPtr struct that frees
> the pointer once it goes out of scope. It overrides assignment and copy
> ctors such that an OwnerPtr becomes null after it gets copied to another
> OwnerPtr (it has move semantics, and disables copy).
> 
> An OwnerPtr can be copied into a regular pointer, under the condition
> that the regular pointer is scope (it cannot outlive the OwnerPtr
> itself).
> ...

As mentioned above this works if you have only one level of indirection.

> I used to actually use this scheme for memory management back when I was
> writing C/C++ code, and it works fairly well: only back then I didn't
> have 'scope' so there was the danger of a non-owning pointer leaking out
> and becoming a dangling pointer.  With D's scope, this becomes a
> waterproof scheme AFAICT.
> 

Not really. E.g., you can have two non-owning pointers to a Array!int 
and then one of them reassigns the array, while the other borrowed a 
pointer to one of its elements. Rust enforces no mutable aliasing 
exactly because reassigning something may cause the old value to be 
deallocated.