On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
I've toyed with this idea for a while, and wondered what the
interest there is in something like this.
The idea is to be able to use a subset of D that does not
require any of druntime or phobos - it can be linked merely
with the C standard library. To that end, there'd be a compiler
switch (-betterC) which would enforce the subset.
(First off, I hate the name "better C", any suggestions?)
The subset would disallow use of any features that rely on:
1. moduleinfo
2. exception handling
3. gc
4. Object
I've used such a subset before when bringing D up on a new
platform, as the new platform didn't have a working phobos.
What do you think?
I began studying and programming in D primarily to do ARM bare
metal programming in something other than C and C++.
I'm in favor of adding compiler switches like -fno-rtti,
-fno-moduleinfo, -fno-exceptions etc..., but I'm not in favor of
aggregating them under a single name like "-betterC" or "-worseD".
I use GDC with the -fno-emit-moduleinfo switch. In fact, it is
necessary for what I'm trying to do. Right now I have to stub
out the TypeInfo stuff[1] to get things to compile, so a
-fno-rtti switch would be cool, but I still don't understand why
the compiler doesn't just emit whatever TypeInfo stuff I supply,
and nothing if I don't supply it. Discussion here[2]
Automatic Memory Management should be decoupled from the language
as much as possible. Ideally we should just be able to add -lgc,
-larc, -lnone to our linker flags and the language would use a
Garbage Collector, Automatic Reference Counting, or no memory
management respectively. Or something along these lines. I
don't know what the right solution is. Just make it transparent
to the language and an option to the programmer. I realize this
is easier said than done, though.
BOTTOM LINE:
I don't want a better C. I want a better D.
[1]
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/memory-mapped-io/source/object.d
[2]
http://forum.dlang.org/post/jynxfglpulguvqbiv...@forum.dlang.org
Mike
