On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright
wrote:
that does not even help you in sticking with that crippled
subset.
Is there a point to having a compiler flag that'll warn you if
you use "pure"?
Ugh, how "pure" is relevant? (I have not tried it but would
expect it to work in C-like code, it is just an annotation after
all). I am speaking about control about hidden allocations / gc,
referring to TypeInfo's and stuff like that. Stuff you get in C
out-of-the box because it does no clever magic. In D right now
all you can is to get rid of runtime and check for linker errors
- not impossible to do, but clearly less convenient than
compile-time errors.
Off the top of my head:
1. compile speed
Only partially true. Large projects need separate compilation and
D does not behave that good in such scenario. Still better than
C, but not good enough to make a difference.
2. dependable sizes of basic types
Not a real issue as your platform SDK always includes some kind
of "stdint.h"
3. unicode
Number one my list of advantages. Does not apply to plenty of
projects though.
4. wchar_t that is actually usable
Same as (3)
5. thread local storage
It is lot of pain and source of problems, not advantage. Extra
work to hack the druntime to get stuff working on barebone.
6. no global errno being set by the math library functions
This has made me smile :) It shows how different applications we
have in mind speaking about "C domain".
7. proper IEEE 754 floating point
Potentially useful but largely mitigated by platform-specific
development.
8. no preprocessor madness
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?
9. modules
Other than (1) it is also more a problem than help in current
implementation - you need to care also about emitted ModuleInfo.
10. being able to pass array types to functions without them
degenerating to pointers
Agreed,
11. inline assembler being a part of the language rather than
an extension that is in a markedly different format for every
compiler
Not an issue. You almost always stick to specific compiler in
barebone world (one adapted for your platform).
12. forward referencing (no need to declare everything twice)
Not an issue. C programmers are not tired from typing.
13. no need for .h files
Same as (9)
14. no ridonculous struct tag name space with all those silly
typedef struct S { ... } S;
declarations.
Nice but just a syntax sugar yet again.
15. no need for precompiled headers
Same as (9)
16. struct alignment as a language feature rather than an ugly
extension kludge
Same as (11)
17. no #include guard kludges
OH MY GOD EXTRA <10 LINE OVERHEAD PER HEADER
18. #define BEGIN { is thankfully not possible
Very tempting but partially mitigated by (8)
19. no need for global variables when qsorting
Doesn't matter
20. no global locale madness
(no idea what this means)
And if you use D features even modestly, such as auto, purity,
out variables, @safe, const, etc., you can get a large
improvement in clarity in function APIs.
`auto` has no real value in C world because there are not crazy
template types. @safe is a joke for barebone, you almost never be
able to apply it :) Purity, transitive immutability - yeah, those
are also top reasons in my list why I'd really love to see D in
that domain.
But most of those advantages are high-level advantages. To get
there and make use of those you need to get through issues that
hit you from the very beginning and frustrate _before_ you can
see how awesome high-level stuff is:
- Allocation for stuff like array literals making those unusable
once you remove runtime away
- No internal linkage or reliable LTO - no way to take care of
unused symbols and control binary size / layout
- Requried to stub out TypeInfo / ModuleInfo to use literally
anything
Note that those are not _fundamental_ language issues. It is
possible to fix those via slight tweaks to compiler / spec. But
it is state of affairs right now and I need to include time
estimates to implement those any time when asked how feasible
would have been to use D in that domain (some of my old
colleagues have been casually asking me about it).
