• cam-bam (15/15) Apr 19 Will `-betterC` continue to evolve to support more language
• Dave P. (3/7) Apr 19 Which high level features that are unsupported do you think
• Derek Fawcus (2/10) Apr 19 Isn't there some of the compile time execution stuff missing?
• Jonathan M Davis (28/43) Apr 19 The goal with betterC was to make it easier to port C code to D. It was
• Walter Bright (1/1) Apr 19 BetterC gets the D features that don't require the D runtime.

cam-bam <cam-stand gmail.com> writes:

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

Dave P. <dave287091 gmail.com> writes:

On Saturday, 19 April 2025 at 16:18:22 UTC, cam-bam 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?

 [...]

Which high level features that are unsupported do you think 
betterC could support?

Derek Fawcus <dfawcus+dlang employees.org> writes:

On Saturday, 19 April 2025 at 18:33:54 UTC, Dave P. wrote:
 On Saturday, 19 April 2025 at 16:18:22 UTC, cam-bam 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?

 [...]

 Which high level features that are unsupported do you think 
 betterC could support?

Isn't there some of the compile time execution stuff missing?

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

Walter Bright <newshound2 digitalmars.com> writes:

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