Signed word lengths and indexes

[Walter Bright]

bearophile wrote:
> Walter Bright:
> 
>>> But I can say that D is already not the best language to develop non-toy
>>> operating systems.
>> Why?
> 
> I have not written an OS yet, so I can't be sure. But from what I have read
> and seen D seems designed for different purposes, mostly as a
> high-performance low-level application language that currently is programmed
> in a style that doesn't assume a very efficient GC.

I'd rephrase that as D supports many different styles. One of those styles is as 
a "better C".


> D has many features that are useless or negative if you want to write code
> close to the metal as a kernel, as classes, virtual functions, garbage
> collector, operator overloading, interfaces, exceptions and try-catch-finally
> blocks, closures, references, delegates, nested functions and structs, array
> concat, built-in associative arrays, monitor, automatic destructors. When you
> write code close to the metal you want to know exactly what your code is
> doing, so all the automatic things or higher level things become useless or
> worse, they keep you from seeing what the hardware is actually doing.

I agree on those points. Those features would not be used when using D as a 
"better C".

So, you could ask why not use C++ as a "better C" and eschew the C++ features 
that cause trouble for kernel dev? The answer is that C++ doesn't offer much 
over C that does not involve those trouble causing features.

D, on the other hand, offers substantial and valuable features not available in 
C or C++ that can be highly useful for kernel dev. Read on.


> On the other hand current D language (and C and C++) lacks other
> hard-to-implement features that allow the kernel programmer to give more
> semantics to the code. So such semantics has to be expressed through normal
> coding. Future languages maybe will improve on this, but it will be a hard
> work. ATS language tries to improve a bit on this, but it's far from being
> good and its syntax is awful.

I think you are giving zero weight to the D features that assist kernel programming.


> D also lacks a good number of nonstandard C features that are present in the
> "C" compiled by GCC, such low-level features and compilation flags can be
> quite useful if you write a kernel. Even LDC has a bit of such features.

A non-standard feature means the language is inadequate. There is nothing at all 
preventing non-standard features from being added to D for specific tasks. There 
is no reason to believe it is harder to do that for D than to C.

As for standard features D has that make it more suitable for low level 
programming than C is:

1. inline assembler as a standard feature
2. const/immutable qualifiers
3. identification of shared data with the shared type constructor
4. enforced function purity
5. guaranteed basic type sizes
6. arrays that actually work
7. scope guard (yes, even without exception handling)

BTW, you might ask "how do I know my D code doesn't have exception handling or 
GC calls in it?" There are several ways:

1. Remove the support from it from the library. Then, attempts to use such 
features will cause the link step to fail. Kernel C programmers use a custom 
library anyway, no reason why D kernel dev cannot.

2. Compiling code with "nothrow" will check that exceptions are not generated.

3. The compiler could be easily modified to add a switch that prevents such 
features from being used. This is no different from the customizations done to C 
compilers for kernel dev.