Memory management design

[JS]

On Wednesday, 10 July 2013 at 10:56:48 UTC, Paulo Pinto wrote:
> 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.
>

I agree but it's not going to happen ;/

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

I don't know if that is a solid statement. ARC is pretty 
different from AGC.

I personally think memory management should be up to the 
programmer with some sort of GC as a fallback, ideally 
optional... maybe even selectable at run-time.