DIP74: Reference Counted Class Objects

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 26 14:39:21 PST 2015


Am Thu, 26 Feb 2015 13:50:55 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy
> and discuss.
> 
> Thanks,
> 
> Andrei

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.


"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?


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



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?
* 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?
* Owned
  Supported by the member variables lifetime = parent lifetime rule?
* Unique
  ?
* ?


More information about the Digitalmars-d mailing list