On 2015-02-26 22:50, Andrei Alexandrescu wrote:
http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
discuss.
* What will happen if these methods are defined on a class that is
allocated on the GC? Is there any enforcement against this? Is there any
way an unsafe operation can happen, i.e. the GC deleting a class that
has already been destroyed by reference counting?
What about enforcing a third method, "allocate" or similar. This method
will do the actually allocation of a class instance. "new Foo" could be
lowered to a call to "allocate".
* I know this is bikeshedding but I think it's important. This is a
breaking change, like it or not, and it's the worst kind. The kind that
if a class exists with these methods it will continue to happily compile
without errors or warnings but will have different semantic behavior.
Therefore I recommend requiring a compiler recognized UDA, in one of the
following ways:
A.
@arc class Foo
{
T1 opAddRef();
T2 opRelease();
}
If a class is marked with @arc the compiler will enforce that both
"opAddRef" and "opRelease" are defined with the expected signatures.
B.
class Foo
{
@arc T1 opAddRef();
@arc T2 opRelease();
}
If either a method is called "opAddRef" or "opRelease" and it's marked
with @arc, the compiler will enforce that the other method is defined
and marked with @arc as well. The signatures of the methods are enforced
as well.
C.
class Foo
{
@arc("addRef") T1 foo();
@arc("release") T2 bar();
}
Basically the same as B but the actual methods can be called anything.
Alternative A gives a clear documentation it's a reference counted class
without having to scan the methods.
--
/Jacob Carlborg
