BetterC added features?

[Jonathan M Davis]

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