On Wednesday, 12 November 2014 at 12:57:58 UTC, Marc Schütz wrote:
On Wednesday, 12 November 2014 at 06:48:47 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 03:13:20 UTC, Rikki
Cattermole wrote:
[...]
yes and no. The ideas is similar, but it is not doable at
library level if we want to get safety and the full benefit
out of it, as it would require for the compiler to introduce
some call to the runtime at strategic places and it does
interact with @nogc.
I'm not sure. A library implementation may be feasible. For
invalidation, the objects can be returned to their init state.
This is "safe", but maybe not ideal, as a compiler error might
indeed be better. Even implicit conversion to shared &
immutable will be possible with multiple alias this, though
it's worth discussing whether an explicit conversion isn't
preferable.
As for @nogc, I see it as a clutch that's needed while no
"real" solution is available, and as a tool for aiding
transition once we have one.
That said, some compiler support will definitely be necessary.
I now remember that I played around with a related idea when
Andrei suggested his template solution (but without the islands
part):
http://wiki.dlang.org/User:Schuetzm/RC,_Owned_and_allocators
The important part is that owning, RC and GC types all need to
know the allocators they belong to. In my example I need that to
allow Owned types to be converted to RC types. In your proposal,
something similar will ultimately be needed for merging the
islands into specific heaps. The nice thing is that this scheme
also allows for switching allocators on the fly at runtime,
without template bloat, at the cost of virtual calls for using
the allocators (which is probably an acceptable compromise for an
inherently expensive thing like allocation).
