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
