Am Thu, 26 Feb 2015 13:50:55 -0800 schrieb Andrei Alexandrescu <[email protected]>:
> 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 ? * ?
