Memory management design

[Paulo Pinto]

On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
> 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.

I do agree D needs something like @nogc, something like untraced 
pointer as I mentioned.

What I am speaking against is making GC a opt-in instead of the 
default allocation mode.

In such case it looks more as a workaround instead of fixing the 
real problem, which is having a better GC.

Note that by GC, I also mean some form of reference counting with 
compiler support to minimize increment/decrement operations.

--
Paulo