Beta 2.079.0

[Mike Franklin]

On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:

> Huh? Did I understand right? Just add an empty object.d into 
> your project and --BetterC is now basically needless, plus the 
> executable is most likely even smaller?

Kindof, but not exactly.  The -betterC switch still adds some 
nuance such as...

> assert failures are directed to the C runtime library
https://dlang.org/spec/betterc.html

... just to name one.

Though, with 2.079, you should be much less constrained in your 
no-/partial- runtime implementation.

For example, I'm exploring a minimal runtime implementation for 
using D on bare-metal microcontrollers 
(https://github.com/JinShil/stm32f42_discovery_demo)  The device 
tree (i.e. bus/peripherals/registers/bitfields) is statically 
known at compile-time.  I use this pattern to model the device 
tree...

final abstract class RCC : Peripheral!(AHB1, 0x3800)
{
     final abstract class CR : Register!(0x00, 
Access.Byte_HalfWord_Word)
     {
         alias PLLSAIRDY = Bit!(29, Mutability.r);
         alias PLLISAION = Bit!(28, Mutability.rw);
     }
}
https://github.com/JinShil/stm32f42_discovery_demo/blob/93f2c53578a18e8ce8e6a3985db14f361590f07f/source/stm32f42/rcc.d#L24

That would be impossible with -betterC, because -betterC doesn't 
support classes.

I suspect others will find more compelling use cases.

With 2.079 it may also be possible to implement certain features 
of D that are disabled in -betterC by providing custom 
implementations of runtime hooks 
(https://wiki.dlang.org/Runtime_Hooks) or other features in the 
runtime.

I'm of the opinion, however, that with the right changes to the 
compiler-runtime coupling, as demonstrated in 2.079, a better C 
can be achieved without the -betterC compiler switch.  There's 
still more work to be done, though, and the -betterC compiler 
switch will still have its uses.  It should be noted, however, 
that it was the work done on -betterC that made the changes in 
2.079 possible.

Mike