On 12/12/2013 3:16 AM, Dicebot wrote:
To remove all "smart"
side-effects in D you need to get rid of all druntime, avoid
using some language features and resort to inline assembly
relatively often.
I don't see why you'd have to resort to inline assembler in D any more than in
C.
But it leaves you with a very crippled language
Not more "crippled" than C is.
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"?
At this point you really start asking
yourself - what does this give me over raw C to motivate the
transition? So far I don't see anything convincing.
Off the top of my head:
1. compile speed
2. dependable sizes of basic types
3. unicode
4. wchar_t that is actually usable
5. thread local storage
6. no global errno being set by the math library functions
7. proper IEEE 754 floating point
8. no preprocessor madness
9. modules
10. being able to pass array types to functions without them degenerating to
pointers
11. inline assembler being a part of the language rather than an extension that
is in a markedly different format for every compiler
12. forward referencing (no need to declare everything twice)
13. no need for .h files
14. no ridonculous struct tag name space with all those silly
typedef struct S { ... } S;
declarations.
15. no need for precompiled headers
16. struct alignment as a language feature rather than an ugly extension kludge
17. no #include guard kludges
18. #define BEGIN { is thankfully not possible
19. no need for global variables when qsorting
20. no global locale madness
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.
