On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:
Is getting a whole lot better:
https://github.com/dlang/dmd/pull/6918
You can now build D executables that do not link in anything
from Phobos - only from the standard C library.
While it's encouraging to see some attation given to this
feature, I think the fundamental premise motivating -betterC is
misguided.
Rather than requiring a switch that bluntly disables certain
features of the language, the compiler and/or linker should
simply not require implementations that aren't explicitly or
implicitly used. For example, if one is not doing any dynamic
casting or other runtime inspection, the toolchain should not
throw any errors about a missing TypeInfo implementation, and the
toolchain certainly shouldn't add automatically generated
TypeInfo implementations to the binary that have no hope of every
being referenced or executed.
As I understand it, this requires some cooperation between the
compiler and the linker. For example, the compiler may not be
able to determine whether or not a certain language feature or
implementation is required, so it will include a link to it
anyway in the intermediate object file, but the linker will be
able to see that there is no possible logic path to that code in
the final binary, and can strip it out rather than generate an
unresolved symbol error. GCC's
-ffunction-sections/-fdata-sections and ld's --gc-sections do
this quite well, though better implementations may also be
possible with LTO features.
I think all features of D have their place even in bare metal and
resource constrained microcontroller programming. For example,
despite the disdain from others, I use C++ exceptions in much of
my microcontroller programming because it makes the "happy path"
a little bit faster at the expense of making the "unhappy path"
(whose performance doesn't matter) much slower. It also makes my
code much easier to reason about, and escape out of when
something goes wrong.
Similarly, I can also see TypeInfo and ModuleInfo being useful
for certain applications. For example, ModuleInfo and module
constructors may be a good way to initialize peripherals before
calling main(). However, the toolchain shouldn't require
TypeInfo and ModuleInfo to always be there just to get a build
when they have no chance of ever being referenced or executed in
the final binary.
If one wanted to avoid certain druntime dependencies, they should
be able to simply avoid those features of D in their source code
for which there is no runtime implementation (e.g. exceptions,
classes, AAs, etc...) or provide their own implementation
embedded in their code that overrides the druntime implementation.
On a system with a full desktop-like operating system it would be
convenient to automatically link in druntime and maybe Phobos,
but that should be done on a platform-by-platform basis in either
a dmd.conf, linker script, or some other similar configuration
file that is distributed with the toolchain's package.
I think it would be better to refactor the DMD and druntime
implementations to reduce their coupling and improve their
cooperation with the linker and LTO features. In doing so, a
-betterC switch would be rendered redundant and ultimately
needless.
Mike
