DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

On Sunday, 11 October 2015 at 23:07:18 UTC, Ola Fosheim Gr wrote:
> On Sunday, 11 October 2015 at 22:33:44 UTC, Jonathan M Davis 
> wrote:
> Well, the wrapper approach is no good (is it part of dip74?) 
> since it messes up alignment etc, so the refcount interface 
> should be part of the parent object. The child can be given the 
> Refcount interface from dip74, it won't use it for a weak 
> reference until it dereference (borrow). A weak reference just 
> delays destruction until the borrowing is completed.

DIP 74 proposes built-in reference counting. There is no wrapper 
type, and the compiler is able to elide increments and decrements 
of the ref count if it determines that they're unnecessary. If a 
type is ref-counted with DIP 74, it's always ref-counted, and it 
doesn't have anything for weak references (presumably leaving 
that up to the GC to take care of).

>> get used incorrectly. But part of the whole point of DIP 74 is 
>> so that we can have @safe ref-counting in D.
>
> Well, @safe in D is broken and should just be dropped in favour 
> of something sane like real pointer analysis instead of piling 
> up bad designs like dip25. You only have to run it for 
> release... Who cares if it is slow?

@safe isn't going anywhere. And it mostly works just fine. It's 
primary flaw is that it's been done via blacklisting operations 
rather than whitelisting them, but that doesn't stop it from 
working. It just makes the implementation more error-prone. The 
only thing preventing the use of @safe in most cases is functions 
that haven't been updated to use it yet (in which case @trusted 
can be used). Walter and Andrei are completely behind @safe and 
are going to be in favor of fixing any holes in it that are 
found, not getting rid of it. And I don't see any reason why that 
can't work or that it's a bad idea.

- Jonathan M Davis