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.
