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.
