On Thu, 23 Apr 2009 15:08:43 +0400, bearophile <bearophileh...@lycos.com> 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?