On 11 October 2015 at 16:17, deadalnix via Digitalmars-d <[email protected]> wrote: > On Sunday, 11 October 2015 at 06:10:32 UTC, Jonathan M Davis wrote: >> >> On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote: >>> >>> On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote: >>>> >>>> [...] >>> >>> >>> Speaking of DIP74 can't we just wrap a class in a struct with use >>> reference counting with and use alias this? >> >> >> alias is problematic, because it allows the class reference to escape. >> opDispatch doesn't have that problem, though there may be other >> complications that it introduces (I don't know). It does get kind of >> complicated though when you consider member functions which return the a >> reference to the object and things like that. So, while it's generally >> feasible, it's not that hard for it to become unsafe. How much that matters >> is debatable, but it could make it so that reference counting classes is >> infeasible in @safe code. >> >> - Jonathan M Davis > > > Ok dispatch has that problem. You can escape the this pointer from within > member functions. Always. There is no @safe reference counting without > language support. Either the RC is backed into the language (DIP74) or > ownership is baked into the language, so that RC can be baked into the > library.
Ownership is only part of the problem (and I support your ideas about ownership, I think D is completely going the wrong way on ownership). There is still the problem that the inc/dec primitives need to be known for the compiler to optimise. Constructors/destructors don't do it semantically. That seems to be what DIP74 is introducing, and even if the ownership problems were addressed/improved, DIP74 would just remap to those concepts. We still need the inc/dec primitives either way.
