Componentizing D's garbage collector

[deadalnix]

On Wednesday, 15 January 2014 at 00:24:48 UTC, Frustrated wrote:
> On Tuesday, 14 January 2014 at 22:36:12 UTC, Benjamin Thaut 
> wrote:
>> Am 14.01.2014 23:10, schrieb Walter Bright:
>>>
>>> I already agreed that there are better ways.
>>>
>>
>> Then this was a big misunderstanding.
>
> So, the issue seems to be that everyone is treating the GC as 
> the Thors hammer and seeing everything as a nails?
>
> The GC does and can not solve all problems. Why force people to 
> use it when it doesn't work well?
>
> I would think having a multi-layered approach would be best. 
> Allow the GC to do everything it can but also allow it to be 
> configured from 0 to 60. For noobs, non-realtime apps, etc the 
> GC can be set to do it all. One can trade speed for memory(less 
> memory, more scanning etc...). One can disable to in specific 
> cases(such as on unions), have separate heaps for GC memory and 
> non-GC allocated memory, etc.
>
> It seems that a more robust GC with many features(with the 
> feature of not using it and either manually allocating or using 
> ARC).
>
> The the only real issue becomes how to keep the GC in sync with 
> the non-GC allocated memory... and this only happens if one 
> chooses to use non-GC features(which must be intentional so 
> hopefully the programming knows what he's doing if he got that 
> far).
>
> I doubt this will ever be possible to solve efficiently so why 
> bother? Leave it up to the programmer to deal with it. Make 
> some resources available to solve these problems but don't try 
> to dictate what must be done. If the programmer is going to 
> bypass the GC he already must have good reasons so why put up 
> roadblocks? Cause *you* think you know better than him what he 
> needs to do?
>
>
> For example, suppose we have a non-GC based pointer. Allow the 
> programmer to mark it as a pointer with certain contextual 
> parameters so that either the GC ca n "deal with it" better or 
> at least for debugging purposes help find memory leaks.
>
> I'm way more interested in having a GC that doesn't stop the 
> world and a compiler that doesn't require the GC for simple 
> stuff as slices(could it not use a buffer and/or ARC 
> instead/alternatively?).

Try to do the pull request that goes with that, and we will be
able to discuss the real problems.