Walter Bright:
Thank you for your answers.
D removes very little bound checks. No data flow is used for
this.
This is false.
Oh, good, what are the bound checks removed by the D front-end? I
remember only one case (and I wrote the enhancement request for
it). Recently I argued that we should add a little more removal
of redundant bound checks. But probably the "GC and C++" mantra
is more urgent thank everything else.
This is on purpose, because otherwise about half of what enums
are used for would no longer be possible - such as bit flags.
On the other hand we could argue that bit flags are a
sufficiently different purpose to justify an annotation (as in
C#) or a Phobos struct (like for the bitfields) that uses mixin
that implements them (there is a pull request for Phobos, but I
don't know how much good it is).
D module system has holes like Swiss cheese. And its design is
rather simplistic.
Oh come on.
ML modules are vastly more refined than D modules (and more
refined than modules in most other languages). I am not asking to
put ML-style modules in D (because ML modules are too much
complex for C++/Python programmers and probably even unnecessary
given the the kind of template-based generics that D has), but
arguing that D modules are refined is unsustainable. (And I still
hope Kenji fixes some of their larger holes).
- no implicit type conversions
D has a large part of the bad implicit type conversions of C.
D has removed implicit conversions that result in data loss.
Removing the rest would force programs to use casting instead,
which is far worse.
This is a complex situation, there are several things that are
suboptimal in D management of implicit casts (one example is the
signed/unsigned comparison situation). But I agree with you that
this situation seems to ask for a middle ground solution. Yet
there are functional languages without implicit casts (is Rust
allowing implicit casts?), they use two kinds of casts, the safe
and unsafe casts. I think the size casting that loses bits is
still regarded as safe.
- had a sane macro system
There's no macro system in D. Mixins are an improvement over
the preprocessor,
but they lead to messy code.
D doesn't have AST macros for very deliberate reasons,
discussed at length here. It is not an oversight.
I am not asking for AST macros in D. I was just answering to a
laundry list of things that C doesn't have (I was answering that
D doesn't either).
But I guess D already covers it...
D solves only part of the problems. And you have not listed
several important
things. There's still a lot of way to go to have good enough
system languages.
D does more than any other system language.
Perhaps this is true (despite Rust is more more refined/safer
regarding memory tracking), that's why I am using D instead of
other languages, despite all the problems. But fifteen years from
now I hope to use something much better than D for system
programming :-)
Bye,
bearophile
