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