On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:
...
### Dennis
Dennis asked about the future direction of `-betterC`...
... He then listed three possible approaches:
* Explicitly annotate code as CTFE-only with new syntax:
`pragma(ctfe)`, `if (ctfe)` etc. Walter noted that the syntax
is an extra `()`.
* Implicitly make functions using DRuntime features as
CTFE-only. This might be surprising and unintuitive
* Generate run-time errors instead of compile-time errors. This
makes errors easier to slip by.
Martin suggested a fourth option: phase out `-betterC` because
it's a "pile of hacks"...
As a final question, Dennis asked what the "official" intended
use for BetterC was in the first place: just a C migration tool
or also something for new D code. I said `-betterC` shouldn't
be used for writing new code. Walter said it can be used for
whatever calls for it, be it integrating with C, targeting
embedded systems, or any scenario where you don't want to link
DRuntime.
...
In the recent post by Mike Parker, betterC is used as a great
alternative to C for writing bare-metal RISC-V application:
https://forum.dlang.org/post/eemwycjmfqvedgggn...@forum.dlang.org
