Memory management design

[BLM768]

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

It's possible to use your own memory model, but that doesn't mean 
it's necessarily convenient or safe, and there's no standardized 
method of going about it. If it becomes standardized, there's a 
much higher chance of the core library using it.

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

Memory management and memory allocation are not the same issue; 
from a purely theoretical standpoint, they're nearly orthogonal, 
at least without a compacting collector. If the both the GC and 
the allocators are designed in a sufficiently flexible and 
modular manner, it would be possible to tie several 
general-purpose allocators to the GC at once. There are some 
allocators that can't be shoehorned into the GC model, but those 
would just return non-GC references.

On Wednesday, 10 July 2013 at 07:59:41 UTC, Dicebot wrote:
> I think merging "scope" and "owned" can be usable enough to be 
> interesting without introducing any new concepts. Simply make 
> it that "scope" in a variable declaration means it is a 
> stack-allocated entity with unique ownership and "scope" as a 
> function parameter attribute is required to accept scope data, 
> verifying no references to it are taken / stored. Expecting 
> mandatory deadalnix comment about lifetime definition ;)

Most of the functionality of "owned" is redundant, but there are 
still some corner cases where it could be useful. The idea behind 
it is to have it function very much like a pointer in C++ code. 
For non-reference types, you could just use a pointer, but using 
a pointer with reference types introduces an extra dereference 
operation to get to the real data.

This is something that could be implemented as a library type 
rather than an intrinsic part of the language, and that would 
probably be better because it's really sort of a low-level tool.

> Only thing I have no idea about is if "scope" attribute should 
> be shallow or transitive. Former is dangerous, latter severely 
> harms usability.

I'm not sure how shallow "scope" would be dangerous. If a "scope" 
object contains non-scope references to GC-allocated data, it's 
perfectly safe to stash those references somewhere because the 
target of the reference won't be collected. If the object 
contains "scope" members (if the language even allows that), then 
references to those members should actually inherit the 
container's "scope" status, not the members' "scope" status, 
because "scope" would be "overloaded" in that case to mean 
"packed into a (potentially heap allocated) object". "scope" is 
all about where the objects might be allocated, which is not a 
transitive property.