DIP74: Reference Counted Class Objects

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 26, 2015 at 01:50:55PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
> discuss.
[...]

Under "Rules":
> The complexity of this code underlies the importance of making
                              ^^^^^^^^^
			      Should be "underlines"

> opAddRef and especially opRelease nothrow. In that case the
> scope(failure) statement may be elided.


Under "Rules":

> struct, class, and closure types that have RCO members accommodate
> calls to Release during their destruction.

This is unclear to me. What exactly is the semantics of "accomodate
calls to Release"? And what is "Release"? Did you mean opRelease?

Also, the code example following is also unclear; since struct A has no
RCO members that I can see, does that mean the calling sequences
(labelled 1-9) apply to *all* structs now? Is Widget supposed to be RCO
(this is not stated clearly)?

Similarly, in the next example about fun(exprA, exprB, exprC) it's not
clear exactly which parameter is supposed to be RCO. I can guess, but
it's better to be 100% unambiguous.


Then the rule that states that opAddRef and opRelease are not issued for
'this': is this safe from race conditions? E.g., if I'm inside a method
and somebody outside calls opRelease and frees the object 'this' points
to. Or are we assuming that RCOs must be thread-local? If so, this
should be stated explicitly.


Under "Relinquishing an owned resource":

> The method is correctly not annotated with return because the slice it
> returns is not scoped by this. Note that if the implementer of Widget
> forgets the assignment _payload = null, user code may end up with a
> dangling reference. 

So basically such a method cannot be marked @safe, right?


T

-- 
Only boring people get bored. -- JM