DIP74: Reference Counted Class Objects

[Andrei Alexandrescu via Digitalmars-d]

On 2/26/15 2:39 PM, Johannes Pfau wrote:
> Looks very nice, some things to refine:
>
> "Any attributes are allowed on these methods."
> * Should @safe and @trusted by disallowed as
>    "@safe code may not issue explicit calls to
>     opAddRef/opRelease"?
> * Probably also add a note here that the functions must be inverse and
>    a note that they should be nothrow and/or final for performance.

OK. I don't want to impose many limitations - let users explore 
possibilities. I added the recommendation.

> "This DIP proposes @safe reference counted class objects (including
> exceptions)"
> * Unfortunately the DIP doesn't talk about exceptions ;-) Will we
>    simply make Throwable a RCO?

Yes.

> "considers that opRelease is the inverse of opAddRef, and therefore is
> at liberty to elide pairs of calls"
> * Nice, but does that mean that reference-counted classes are now
>    superior to reference counted structs? It would be nice if the
>    compiler could also detect opRelease/opAddRef in structs. We could
>    still require user code to call these manually in postblits etc but
>    recognizing them would allow eliding pairs.

That's already taken care of - this(this) and ~this() are considered 
complementary.

> Also a more general question: What are the most important memory
> management strategies and which are handled by DIP25+DIP74?
> * GC
>    Of course supported
> * RC
>    Supported with DIP74. I think this could also be considered as ARC.
>    If not, what is missing from DIP74 compared to ARC?

Unless something major we didn't think of is found with DIP25 and DIP74, 
it's not impossible we found the perfect shade. Not only we'll offer 
automatic reference counting, but we'll allow people do define types 
that are usable in @safe code that do that.

> * Scoped (useful for stack objects)
>    Can 'return' be used to implement something which allocates a class
>    on the stack and prevents escaping references? I guess a Scope
>    struct allocating in place + a function returning a reference to the
>    class with 'return' (+ alias this) would work?

Yah, DIP74 can be directly used to make "scope w = new Widget;" work. 
But we'll address that in a distinct DIP in order to not bloat this one.

> * Owned
>    Supported by the member variables lifetime = parent lifetime rule?
> * Unique
>    ?
> * ?

Let's see.


Andrei