Programming Language for Games, part 3
bearophile via Digitalmars-d
digitalmars-d at puremagic.com
Sat Nov 1 18:41:15 PDT 2014
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
More information about the Digitalmars-d
mailing list