Migrating dmd to D?

[js.mdnq]

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