manual memory management

[eles]

On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote:
> On 1/7/2013 3:11 PM, H. S. Teoh wrote:

> One thing I'd add is that a GC is *required* if you want to 
> have a language that guarantees memory safety, which D aims to 
> do. There's an inescapable reason why manual memory management 
> in D is only possible in @system code.

I think that, at least for @system code (or invent another @), D 
programs should be able to require only GC-free code (forbiding, 
for example, features requiring GC).

I do some Linux kernel code. For most of it, I find it quite 
difficult to rely on the GC if I would use D instead of C.

One specific question: when handling an interrupt in Linux 
kernel, you are not allowed to sleep. But I think GC (and 
GC-triggering features) will sleep. So their use should be 
forbidden.

The main difference wrt to C programming for kernel: in C, to 
avoid sleeping, you need to stay away of some kernel/library 
functions; in D, you need to stay away of some language features.

Is one thing to avoid using specific functions. Is another thing 
to avoid using specific language constructs.