DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Sunday, 11 October 2015 at 06:48:54 UTC, Manu wrote:
> I don't really see that DIP25 and DIP74 are particularly 
> closely related.

Ho they are. It is all about ownership.

> DIP25 is a lame cop-out with respect to scope. I was a major 
> backer of
> a proper scope implementation, and given that, I don't/didn't 
> support
> DIP25 at all.
>

DIP25 being a sorry excuse for ownership is the very reason DIP74 
is needed. Rust can do reference counting just fine all in 
library without need for core language support.

> DIP74 on the other hand introduces 2 magic functions that the 
> compiler calls as the appropriate moments to implement ref 
> counting. The implementation is somewhat detail, theoretically 
> changeable in the future, but I think language support for 
> ref-counting primitives is critical for ref counting to be 
> efficient and simple. Look at C++, and we see a disaster. C++ 
> basically implemented rval-references to improve (not solve) 
> the RC problem... we don't have rval-ref's in D, so we're 
> screwed from the library angle.
>

C++ ref counting is not slow for the reasons you think it is. ARC 
is overly complex and also not as fast as you think it is.

First, they are slow because in C++ (or ObjC), you don't know 
what is shared and what isn't. As a result, you got to go the 
pessimistic road and use thread safe ref counting. This can be a 
solved problem in D purely using the type qualifier.

Second, exceptions. Their unwinding makes pair of inc/dec hard to 
recognize, plus now cleanup is need at pretty much every frames, 
meaning incredibly slow exceptions + various control flow 
optimization that aren't possible anymore (tail call being one of 
them).

One that one, nobody has a solution. Not ARC (that's why swift 
does not have exception), not C++ and not us. IMO the obvious 
solution here is to allow ourselves to leak on unwind and rely on 
the GC. Yes, sometime the GC is best. That being said, it is up 
to the application to decide if leaking is acceptable or not, and 
so this can't be baked in the language (this also means that the 
user must be in charge the of deallocation policy, which puts a 
major dent into DIP74).

The 3rd problem is safety. This is where ownership shines.

The 4th problem is elision of refcount operations when not 
needed. Some thing, ownership can solve this. No need to do 
refcount operations when not necessary.

The compiler is perfectly able to optimize pairs of inc/dec 
granted it has the rights infos. And a proper ownership system 
provide the right infos.

> Yup, I was firmly behind scope (ie, borrowing), but that was
> destroyed, and DIP25 kinda cements the death of that :(
>

It is implemented with a flag. That allowed us to try it and get 
real life experience. That is a good thing. We aren't committed 
to it at this stage. And now we have actual experimentation that 
shows that it is too underpowered to be really useful. The smart 
move here is to admit defeat and reconsider.