Other notes

[bearophile]

Here are few more notes on the D language, now I know it enough.

1) At the moment this isn't acceptable in D (but the compiler correctly gives an error instead of doing the wrong thing as some C compilers):

if (0 < a < 5) writefln("***")

Python accepts it and it shows it can be useful (more readable when you define intervals):

>>> a = 10
>>> if 0 < a < 5: print "***"
... 
>>> a = 2
>>> if 0 < a < 5: print "***"
... 
***

(D 2.x has intervals, but I think they can't be used here, even if they define the 'in' operator.)



2) This looks like a bug of DMD v1.023, x isn't initialized, and it prints like garbage:

import std.stdio: writefln;
void main(string[] args) {
  if (args.length > 1) {
    switch (args[1]) {
      int x = 1; // NOT initialized?
      case "1": writefln("1! x=", x); break;
      case "2": writefln("2! x=", x); break;
    }
  }
}



3a) I love the focus D has to avoid bugs, because fixing them sometimes takes more time than writing the program. I think D shows that one of the best ways to avoid bugs is to trash some parts of C and replace them with something better.
With time I hope D to remove some of its redundancy too, this means removing some C/C++ ways, like:
int array[10];
because I belive in "There should be one-- and preferably only one --obvious way to do it." as the zen of Python says.
Cyclone is a language that looks a lot like C, sharing many of its problems, but tries to avoid some common traps (look at the article, it lists some of the things it cheeks):
http://en.wikipedia.org/wiki/Cyclone_programming_language
D tries to be a fast language, while Cyclone is slower than C/D. A possible compromise (that D seem to already partially use) is to activate those cheeks in development mode, and disable them in the final release. Two large sources of bugs that can be handled that way are integer overflows and broken pointers/references. The Delphi/TurboPascal compiler shows that a compilation flag can be added to D that disables *all* integral (char too) overflow cheeks (they are ON by defaul). This helps avoid silly bugs like this too:
writefln("hello".length > -3);
(If the compiler is a bit smart it can avoid part of those overflow cheeks anyway, even when they are switched on).
The second group of runtime cheeks (on pointers/references) can avoid problems with not allocated objects, wrong pointer arithmetic, freeing random parts of memory, etc, and they can be disabled with  -release. (A problem I can see here is that those pointers/references have to become "fat" (because doing a compile time analisys of the code is too much complex), this changes the sizeof of pointers from the development version of the code to the -release version that uses the normal fast thin pointers.)


3b) This D code lacks a ref, maybe the compiler can spot this bug (I have done a mistake like this in the past):

int[10] array;
foreach(i, el; array)
    el = i;


3c) This is a bug that Python avoids, because it doesn't use { } to define blocks. In D leading spaces are ignored but they can be used by the compiler to spot this situation and maybe it can issue a warning:

if (...)
  first();
else
  printf("Calling second()");
  second();


4) Every language feature adds complexity to the compiler, makes the language manual longer, requires programmers to remember more things, etc. So every language feature has to be kept only if enough people use it, without a good way to replace it, etc. I like D real type, but so far I have't found a situation where double can't solve my problem. So who of you is using the real type? If there isn't enough people using it then it may be removed from the D specs.

Bye and thank you,
bearophile