DIP60: @nogc attribute

[Mike via Digitalmars-d]

On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP60
>
> Start on implementation:
>
> https://github.com/D-Programming-Language/dmd/pull/3455

First of all, I have the following suggestions for the DIP:
*  Articulate a more thorough motivation for this feature other 
than to give users what they want.
*  Summarize previous discussions and provide links to them.
*  Provide some justification for the final decision, even if 
it's subjective.

I don't believe users hesitant to use D will suddenly come to D 
now that there is a @nogc attribute.  I also don't believe they 
want to avoid the GC, even if they say they do.  I believe what 
they really want is to have an alternative to the GC.

I suggest the following instead:
1.  Provide the necessary druntime hooks to enable developers to 
create a variety of memory management implementations.
2.  Given these hooks and ideas that have been discussed in the 
community and presented at DConf, improve D's default GC.
3.  Implement a variety of alternative memory managers (official 
and unofficial) that can be compiled and/or linked into druntime 
and/or the program.

Alternative memory managers could include the following:
* Default D2 mark-and-sweep GC for backward compatibility
* Concurrent, precise or otherwise improved D2 mark-and-sweep GC
* Reference counting with mark-and-sweep fallback
* Automatic malloc, manual free
* Manual malloc, manual free
* {Insert your favorite here}

Users can use 'if version(x)' if they wish to support more than 
one memory management scheme, and their choice forces them to 
change their idioms.

I suspect some of the motivation for this is to give customers 
"faster horses".  I would be surprised if a @nogc attribute 
increased D's appeal, and I think efforts would be better 
allocated to some form of the above.

Bottom line:
IMO, memory management is an implementation detail of the problem 
domain, not the language, and it's implementation should be 
delegated to a library or to the programmer.

Mike