Memory management design

[JS]

On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote:
> On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
>> On 10 July 2013 17:53, Dicebot <public at dicebot.lv> wrote:
>>
>>> On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
>>>
>>>> ...
>>>>
>>>
>>> I am pretty sure stuff like @nogc (or probably @noheap. or 
>>> both) will have
>>> no problems in being accepted into the mainstream once 
>>> properly
>>> implemented. It is mostly a matter of volunteer wanting to 
>>> get dirty with
>>> the compiler.
>>>
>>
>> I'd push for an ARC implementation. I've become convinced 
>> that's what I
>> actually want, and that GC will never completely satisfy my 
>> requirements.
>>
>> Additionally, while I can see some value in @nogc, I'm not 
>> actually sold on
>> that personally... it feels explicit attribution is a 
>> backwards way of
>> going about it. ie, most functions may actually be @nogc, but 
>> only the ones
>> that are explicitly attributed will enjoy that recognition... 
>> seems kinda
>> backwards.
>
> That is the approach taken by other languages with untraced 
> pointers.
>
> Actually I prefer to have GC by default with something like 
> @nogc where it really makes a difference.
>
> Unless D wants to cater for the micro-optimizations folks 
> before anything else, that is so common in the C and C++ 
> communities.
>

It's not about any micro-optimizations. Many real time 
applications simply can't use D because of it's stop the world 
GC(at least not without a great amount of work or severe 
limitations).

By having a @nogc attribute people can start marking their code, 
the sooner the better(else, at some point, it because useless 
because there is too much old code to mark). @nogc respects 
function composition... so if two functions do not rely on the gc 
then if one calls the other it will not break anything.

So, as libraries are updated more and more functions are 
available to those that can't use gc code, making D more useful 
for real time applications. If custom allocation methods ever 
come about then the @nogc may be obsolete are extremely useful 
depending on how the alternate memory models are implemented.

Code that only use stack allocation or static heap allocation 
have no business being lumped in with code that is gc dependent.