On heap segregation, GC optimization and @nogc relaxing

[via Digitalmars-d]

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).