Memory management design

[JS]

On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote:
> Given all of this talk about memory management, it would seem 
> that it's time for people to start putting forward some ideas 
> for improved memory management designs. I've got an idea or two 
> of my own, but I'd like to discuss my ideas before I draft a 
> DIP so I can try to get everything fleshed out and polished.
>
> Anyway the core idea behind my design is that object lifetimes 
> tend to be managed in one of three ways:
>
> 1. Tied to a stack frame
> 2. Tied to an "owner" object
> 3. Not tied to any one object (managed by the GC)
>
> To distinguish between these types of objects, one could use a 
> set of three storage classes:
>
> 1. "scope": refers to stack-allocated memory (which seems to be 
> the original design behind "scope"). "scope" references may not 
> be stashed anywhere where they might become invalid. Since this 
> is the "safest" type of reference, any object may be passed by 
> "scope ref".
>
> 2. "owned": refers to an object that is heap-allocated but 
> manually managed by another object or by a stack frame. "owned" 
> references may only be stashed in other "owned" references. Any 
> non-scope object may be passed by "owned ref". This storage 
> class might not be usable in @safe code without further 
> restrictions.
>
> 3. GC-managed: the default storage class. Fairly 
> self-explanatory. GC-managed references may not refer to 
> "scope" or "owned" objects.
>
> Besides helping with the memory management issue, this design 
> could also help tame the hairy mess of "auto ref"; "scope ref" 
> can safely take any stack-allocated object, including 
> temporaries, so a function could have "scope auto ref" 
> parameters without needing to be a template function and with 
> greater safety than "auto ref" currently provides.

One can already choose their own memory model in their own code. 
The issue is with the core library and pre-existing code that 
forces you to use the GC model.

@nogc has been proposed several years ago but not gotten any 
footing. By having the ability to mark stuff has @nogc phobos 
could be migrated slowly and, at least, some libraries would be 
weaned off the GC and available.

I think the use of custom allocators would be better. Plug your 
own memory management model into D.

IMHO nothing will be done because this kinda talk has been going 
on for years(nearly a decade it as some posts go back to 2006).