On 2/5/14, 4:39 AM, Manu wrote:
On 5 February 2014 09:51, Andrei Alexandrescu <seewebsiteforem...@erdani.org <mailto:seewebsiteforem...@erdani.org>> wrote:Consider we add a library slice type called RCSlice!T. It would have the same primitives as T[] but would use reference counting through and through. When the last reference count is gone, the buffer underlying the slice is freed. The underlying allocator will be the GC allocator. Now, what if someone doesn't care about the whole RC thing and aims at convenience? There would be a method .toGC that just detaches the slice and disables the reference counter (e.g. by setting it to uint.max/2 or whatever). Then people who want reference counting say auto x = fun(); and those who don't care say: auto x = fun().toGC(); Destroy. This doesn't excite me at all. What about all other types of allocations? I don't want to mangle my types.
How do you mean that?
What about closures?
This is "#1" and it only addresses slices.
What about allocations from phobos?
Phobos would get added support for RC slices.
What about allocations from 3rd party libs that I have no control over?
Outside the charter of this discussion.
I don't like that it requires additional specification, and special treatment to have it detach to the GC.
But you didn't like that GC is implicit. Which way do you want it?
There's nothing transparent about that.
I don't think we can attain 100% transparency.
Another library solution like RefCounted doesn't address the problem. Counter question; why approach it this way? Is there a reason that it needs to be of one kind or the other?
This is technically possible today. Andrei
