DIP74 - where is at?

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sun Oct 11 00:05:43 PDT 2015


On 11 October 2015 at 16:17, deadalnix via Digitalmars-d
<digitalmars-d at puremagic.com> 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.


More information about the Digitalmars-d mailing list