Dicebot:
2. dependable sizes of basic types
Not a real issue as your platform SDK always includes some kind
of "stdint.h"
On the other hand in D you have less noise. Most D modules you
find around use and will use the built-in types, instead of
choosing every time different ones. This uniformity is an
improvement.
Would have called this a feature if one could actually use
something instead out of the box. But there is no way to
control symbol visibility right now so templates / CTFE are
often out of the toolset. And what to do without those?
This should be fixed.
9. modules
Other than (1) it is also more a problem than help in current
implementation
Despite their flaws, D modules are quite handy, and better than C
way of managing source code files.
you need to care also about emitted ModuleInfo.
I think LDC2 has a pragma to disable module info generation.
Can't something like that be standardized for all D compilers,
including D? Have you opened well reasoned enhancement requests
for your desires?
Not an issue. C programmers are not tired from typing.
That's a silly answer. When it works (and it's working more and
more), the freedom it gives is handy.
Nice but just a syntax sugar yet again.
Having less cluttered code is an improvement.
16. struct alignment as a language feature rather than an ugly
extension kludge
Same as (11)
Having built-in standard features save you troubles and work.
19. no need for global variables when qsorting
Doesn't matter
Why?
20. no global locale madness
(no idea what this means)
I think Walter refers to this kind of stuff:
http://www.cplusplus.com/reference/clocale/
`auto` has no real value in C world because there are not crazy
template types.
"auto" can be handy in C-like code too (but it's less needed
because the types are simpler), to avoid repeating struct names,
to avoid repeating types two times when you call malloc, etc.
@safe is a joke for barebone, you almost never be able to apply
it :)
I think you can have some safe functions in C-style code too :-)
- Allocation for stuff like array literals making those
unusable once you remove runtime away
There is hope to remove this problem:
https://github.com/D-Programming-Language/dmd/pull/2952
https://github.com/D-Programming-Language/dmd/pull/2958
- No internal linkage or reliable LTO - no way to take care of
unused symbols and control binary size / layout
This could be worked on.
And now instead of negatives, let's talk about missing positive
features. A future replacement for the C language should allow
the kind of low level code you use in C, and also offer ways to
express more semantics to the compiler, that will be verified and
enforced, to make the code safer. Currently the only language I
know that is a bit like this is the ATS2 language
(http://www.ats-lang.org/ ), and it's partially a failure. (D and
Rust are more replacements for C++ than for C). There's still
plenty of work to do in the design of low-level languages. A
compiler for such (probably imperative) language will probably
need to contain a SAT solver, and more inference skills.
Bye,
bearophile
