Linus with some good observations on garbage collection

[Kim D]

> On 04/25/2011 10:06 AM, Iain Buclaw wrote:
>> I was thinking of where one implements an alternative runtime that may 
>> not
>> necessarily interface with a GC, or has different semantics on the use of 
>> the
>> keyword (the compiler, after all, doesn't know/care what exactly 'delete' 
>> does, it
>> just does it's job at emitting the correct action we expect from it). 
>> Though it
>> was late night and I perhaps didn't quite put it right anyway.
>>
>> Having literally slept on it though, a runtime with a good GC is one that 
>> doesn't
>> offer a choice to 'delete' memory - so I am on your side.  Though 
>> reflecting from
>> my experience with the D2 GC (thinking from a compiler implementers POV), 
>> there
>> isn't much I can really praise about it.
>>
>> Custom (de)allocators I can also see a very good point for removal too, 
>> however
>> much a stab in the back for those who can use them in the - perhaps 
>> 'one-and-only'
>> - case for a small amount of speed gain.
>>
>> Iain
>
> I understand. The right response to this is defining a good custom 
> allocator API and providing good implementations of it.
>
> Andrei

Sounds like a good way forward. However, certain operations are currently 
not supported unless the GC is enabled, for instance 'Associative Arrays of 
Strings'... do you imagine the future allocator API beeing flexible enough 
to facilitate this use-case in a GC-less environment? Or at least allowing 
more of the functionality which is currently unsupported without GC?

Kim