Herb Sutter gave a pretty interesting talk on zero cost exceptions and RTTI.

https://m.youtube.com/watch?v=ARYP83yNAWk

Could this be an option for D to avoid @gc exceptions?

On 27/09/2019 5:51 AM, shfit wrote:
> Herb Sutter gave a pretty interesting talk on zero cost exceptions and RTTI.
> 
> https://m.youtube.com/watch?v=ARYP83yNAWk
> 
> Could this be an option for D to avoid @gc exceptions?

We have a solution.

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md

I've looked at the dmd and Phobos PR's, I don't know what is currently holding it up from going live.

On Thursday, 26 September 2019 at 18:09:08 UTC, rikki cattermole wrote:

> We have a solution.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
>
> I've looked at the dmd and Phobos PR's, I don't know what is currently holding it up from going live.

I thought it's because RefCount doesn't work without the changes from the @life proposal.

On Friday, 27 September 2019 at 07:53:56 UTC, Dominikus Dittes Scherkl wrote:
> On Thursday, 26 September 2019 at 18:09:08 UTC, rikki cattermole wrote:
>
>> We have a solution.
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
>>
>> I've looked at the dmd and Phobos PR's, I don't know what is currently holding it up from going live.
>
> I thought it's because RefCount doesn't work without the changes from the @life proposal.

what is @life? (searching by forum gives only this message)

On Friday, 27 September 2019 at 09:36:33 UTC, a11e99z wrote:
> On Friday, 27 September 2019 at 07:53:56 UTC, Dominikus Dittes Scherkl wrote:
>> On Thursday, 26 September 2019 at 18:09:08 UTC, rikki cattermole wrote:
>>
>>> We have a solution.
>>>
>>> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
>>>
>>> I've looked at the dmd and Phobos PR's, I don't know what is currently holding it up from going live.
>>
>> I thought it's because RefCount doesn't work without the changes from the @life proposal.
>
> what is @life? (searching by forum gives only this message)

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

On Friday, 27 September 2019 at 09:36:33 UTC, a11e99z wrote:
> On Friday, 27 September 2019 at 07:53:56 UTC, Dominikus Dittes Scherkl wrote:
>> On Thursday, 26 September 2019 at 18:09:08 UTC, rikki cattermole wrote:
>>
>>> We have a solution.
>>>
>>> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
>>>
>>> I've looked at the dmd and Phobos PR's, I don't know what is currently holding it up from going live.
>>
>> I thought it's because RefCount doesn't work without the changes from the @life proposal.
>
> what is @life? (searching by forum gives only this message)

"Life explained as a video game"

https://www.youtube.com/watch?v=ryFjCxGfqeE

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

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.

A "non-owning" pointer cannot be passed to free() (or equivalent). 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.

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).

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.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte

On 27.09.19 09:53, Dominikus Dittes Scherkl wrote:
> On Thursday, 26 September 2019 at 18:09:08 UTC, rikki cattermole wrote:
> 
>> We have a solution.
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md
>>
>> I've looked at the dmd and Phobos PR's, I don't know what is currently holding it up from going live.
> 
> I thought it's because RefCount doesn't work without the changes from the @life proposal.

(Nor with those changes.)

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.

On Thursday, 26 September 2019 at 17:51:16 UTC, shfit wrote:
> Herb Sutter gave a pretty interesting talk on zero cost exceptions and RTTI.
>
> https://m.youtube.com/watch?v=ARYP83yNAWk
>
> Could this be an option for D to avoid @gc exceptions?

Wow this is a really big deal.  Zero-overhead exception with no memory allocation.  Could be a big feature for D.