On Sunday, 3 March 2013 at 12:05:00 UTC, jerro wrote:
Really what is needed is gc arrays and ngc arrays as well as
other essential features. e.g., gc arrays would not be part of
the core spec while ngc arrays would.
You can already use slices without a gc, like this:
T[] allocate(T)(int n)
{
return (cast(T*) malloc(T.sizeof * n))[0 .. n];
}
void deallocate(T)(ref T[] a)
{
free(a.ptr)
a = null;
}
Of course, you can not append to such slices or expand them
without a GC. It would be useful to have a @nogc flag which
would result in an error if a feature that needs a GC was used.
I think adding @nogc would be better than defining a "core
spec", because most D code does not need that feature. If we
add a a @nogc flag, the people that don't need it can just
ignore its existence and do not need to learn about it, but if
we call the subset of D that doesn't use a GC a "core spec",
people will feel that's something they need to learn, which
will make the language seem more complex.
A core spec is not just about gc features. It was also about
migrating the compiler from C++ to D. The core spec can provide
many useful benefits but the gc shouldn't be one of them.
What happens when you append to a slice using manual allocation?
Does the compiler throw an error or just crash and burn? A core
language spec for a self-compiler is required and because it must
be gc agnostic to work across a multitude of platforms(most to
work well with embedded apps or for performance reasons) one
needs a way to signify this(hence marking modules as being
gc-free and having ngc constructs).
For example, by marking a module as core it can only use other
core modules. Since a core module can't use the gc any all arrays
are ngc and gc operations on them would be in error. This also
helps when migrating a module from non-core to core once you get
the module compiled you know it is gc free(as well as other
things).
