On Thu, 23 Apr 2009 15:08:43 +0400, bearophile <[email protected]> wrote:
> Andrei Alexandrescu:
>> The possibility of using D without a garbage collector was always
>> looming and has been used to placate naysayers ("you can call malloc if
>> you want" etc.) but that opportunity has not been realized in a seamless
>> manner. As soon as you concatenate arrays, add to a hash, or create an
>> object, you will call into the GC.
>
> One simple possible solution: -nogc is to write C-like programs, with no
> automatic reference counting. It doesn't include the GC in the final
> executable (making it much smaller) and in such programs AAs and array
> concatenation and closures are forbidden (compilation error if you try
> to use them). "New" allocates using the C heap, and you have to use
> "delete" manually for each of them.
> This is simple. While adding a second memory management system,
> ref-counted, looks like an increase of complexity for both the compiler
> and the programmers.
>
>
Same here. My version of -nogc would work as follows:
1) You mark a module as -nogc/realtime/whatever (similar to module(system) or
module(safe)).
module(nogc) some.module.that.doesnt.use.gc;
2) Array concatenations are not allowed, array.length is readonly, can't insert
into AA, can't new objects (only malloc? this needs additional thoughts)
3) ...
I believe this is an interesting way to explore. When one writes
real-time/kernel-level/etc code that shouldn't leak, he should be very cautious
and compiler should help him by restricting access to methods that
potentially/certainly leak. But how would one ensure that?
A simple idea would be to allow module(nogc) only access other modules that are
marked as nogc, too.
This will effectively disallow most (or all - at least in the beginning) parts
of Phobos (for a reason!).
But marking whole module as nogc is not very good. For example, I'd like to be
able to read from and write to an existing array, but I should be unable to
resize them.
Thus, all the method of Array but a void Array.resize(size_t newSize) must be
marked as safe/noleak/nogc/whatever (nogc is a good name here).
Similarly, safe modules should be able to access other safe methods, to, and T*
Array!(T).ptr() should not be among them.
Thoughts?