dmd -betterC

[Mike via Digitalmars-d]

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