I just read http://wiki.dlang.org/DIP74

and I'm very excited about it :)

What are the plans on making it handle RC-cycles using weak and strong references?

See also:

https://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles

On Wednesday, 8 July 2015 at 11:39:27 UTC, Per Nordlöw wrote:
> I just read http://wiki.dlang.org/DIP74
>
> and I'm very excited about it :)
>
> What are the plans on making it handle RC-cycles using weak and strong references?
>
> See also:
>
> https://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles

We're currently overhauling smart ptrs, like Unique and RefCounted.
Among others we'll add class support, rendering most of DIP74 superfluous.

On Wednesday, 8 July 2015 at 21:55:49 UTC, Martin Nowak wrote:
> We're currently overhauling smart ptrs, like Unique and RefCounted.
> Among others we'll add class support, rendering most of DIP74 superfluous.

But not everything in DIP74 can be implemented as library extension right?

On Thursday, 9 July 2015 at 08:31:39 UTC, Nordlöw wrote:
> On Wednesday, 8 July 2015 at 21:55:49 UTC, Martin Nowak wrote:
>> We're currently overhauling smart ptrs, like Unique and RefCounted.
>> Among others we'll add class support, rendering most of DIP74 superfluous.
>
> But not everything in DIP74 can be implemented as library extension right?

The escape analysis needs to be in the compiler. Proposed DIPs do a poor job at it as they require a bag of tricks instead of a principled approach IMO.

The part where refcount is done can be done via library (and should IMO).

On Thursday, 9 July 2015 at 08:58:22 UTC, deadalnix wrote:
> The part where refcount is done can be done via library (and should IMO).

I think the nice thing about the compiler aware approach is that the compiler could forgo incs/decs when it knows the reference doesn't escape. I'm not sure how much this would actually aid performance in practice though.

On Thursday, 9 July 2015 at 16:49:53 UTC, Brad Anderson wrote:
> On Thursday, 9 July 2015 at 08:58:22 UTC, deadalnix wrote:
>> The part where refcount is done can be done via library (and should IMO).
>
> I think the nice thing about the compiler aware approach is that the compiler could forgo incs/decs when it knows the reference doesn't escape. I'm not sure how much this would actually aid performance in practice though.

There are one case where it is actually useful: when refcounting shared object.

For thread local object, the compiler already have the increment/decrement pair and can optimize accordingly. It can't when the refcount is shared (it always is in many languages like C++ or ObjC) because another thread could have done arbitrary thing to the refcount in the meantime. In that case it is useful, but generally, refcounting shared object have loosy perfs because of contention on the cache line containing the refcount.

The other case where refcounting is bad is when it interract with exceptions. In which case, the language improvement we are talking about here do not help much, and this is why exception are not recoverable in ObjC and absent in swift. A option to make them fast again would be to not decrement the refcount on unwinding, and leak, delegating the cleanup to the GC.

On Thursday, 9 July 2015 at 08:58:22 UTC, deadalnix wrote:
> The escape analysis needs to be in the compiler. Proposed DIPs do a poor job at it as they require a bag of tricks instead of a principled approach IMO.
>
> The part where refcount is done can be done via library (and should IMO).

Right, there are a number of proposals to make a library implementation powerful enough.
http://wiki.dlang.org/DIP69#Scope_Function_Returns
http://wiki.dlang.org/DIP77