On 4/30/14, 1:46 PM, deadalnix wrote:
On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
That means classes that need cleanup (either directly or by having
fields that are structs with destructors) would need to garner that by
other means, such as reference counting or manual. We're considering
deprecating ~this() for classes in the future.
Not sure how I feel about that.
"Ecstatic" is what you're looking for.
This has been proposed as a solution to
some GC issue at last DConf and has been dismissed. Your post is unclear
on why this decision has changed. There must be some new information or
data that inform this decision.
Or is it random ?
I don't remember a proposal being made that made slices of structs with
destructors distinct from other slices.
Also, what about cycle in RC things?
Resource leaks may happen in programs in any language. I'm prepared to
allow leaks in certain cases, and I posit here that such cases are rare
(arrays of objects that embed references to the very array they're in).
Also, RC is good on top of GC, so
you can collect loop, especially if we are going to RC automagically.
That is a major issue.
That stays, and it's useful. I'm talking destructors here.
Finally, immutable is sharable accross thread. That mean, even if we
bypass the type system, that RC must be atomic for immutable.
As they
convert automatically for co,st, that mean that all const code will be
full of atomic increment/decrement. They are bad for the CPU, and cannot
be optimized away.
Good point. I see that as a problem, albeit a solvable one.
That mean we are back to having a const and a mutable version of
functions for performance reasons.
I don't think that's the case. We could and should be able to only use
refcounting for truly immutable slices. (Using a bit in the counter to
indicate sharing comes to mind.)
RCSlice!T will not convert implicitly to void[]. Explicit cast(void[])
will be allowed, and will ignore the reference count (so if a void[]
extracted from a T[] via a cast outlives all slices, dangling pointers
will ensue).
This won't work. array have a lot of magic that cannot be created as
library. ie:
RCSlice!(const T) has nothing to do with const(RCSlice!T) as far as the
compiler is concerned.
We need to improve the language to allow for such. Did I mention it's
not going to be easy?
Andrei
