On Saturday, April 19, 2025 10:18:22 AM MDT cam-bam via Digitalmars-d wrote:
> Will `-betterC` continue to evolve to support more language features in the future, or is it intended to stay minimal and close to C in terms of functionality?
>
> D is a terrific language and I absolutely love it. When I first discovered `-betterC`, I was pleasantly surprised that it still supported powerful features like slices, scope-based resource management `(scope(exit))`, and more—despite omitting the full D runtime.
>
> This made me curious: could we see more high-level features gradually supported in -`betterC`, or is the goal to keep it tightly constrained for low-level systems programming and interoperability with C? In other words, is `-betterC` a minimal subset by design, or is there room for it to evolve and incorporate more D features over time, as long as they don't require the full runtime

The goal with betterC was to make it easier to port C code to D. It was never really the intention that anyone would be writing programs for it without eventually migrating them to proper D.

Either way, the feature set that -betterC has stems from what happens when you remove druntime from the equation. It's not that it has a particular planned set of features. It's what happens when you rip out a core part of D that provides key features. It's certainly possible that some features got ripped out in the process that didn't need to be, but about all I've heard along those lines is that some CTFE stuff doesn't work that arguably should given that while it does use the runtime, it only does so at compile time. So, maybe there will be some improvements there, but I don't know. Certainly, no major features will be added to anything that occurs at runtime with -betterC, because that would require druntime.

And technically, the core D folks are looking to get rid of -betterC in the sense that what we really want is for features to be more "pay as you go." So, for instance, if you're not doing anything that requires module info, then the module info wouldn't be compiled into your program regardless of whether you used a flag such as -betterC. And if we did a better job of that, then -betterC would become redundant in the sense that if you didn't use features, you wouldn't get the stuff that provides them compiled into your program. And so if you programmed in "Better C" instead of proper D, you just wouldn't get the runtime, because you hadn't used anything that required it. Now, maybe -betterC or a similar flag would still be desirable in order to make sure that you didn't accidentally use the runtime, but ideally, what gets pulled in would be defined by what the program actually uses and not by which compiler flags you did or didn't use.

- Jonathan M Davis

BetterC gets the D features that don't require the D runtime.