That D exposes a curated subset of D doesn’t make it a C alternative, even though the ”betterC” aims to target people looking for a C alternative
But why? You comment does not clarify what does this subset lack which prevents it being used as a C alternative. The intention is explicitly stated and the "spirit" argument is weak as overly subjective.
To me, and originally, Dlang was a C++ replacement. However, C and C++ can still be rather mixed despite them being "two different languages"
In my words, BetterC is a tool to help you transition a C programming project to a Dlang one. Turn on the BetterC flag and the transition is quite mild. The goal is to slowly migrate your (now) D code into "proper" D. Then, you can turn off the BetterC flag.
That.. to me.. is the original goal of BetterC. However, I noticed that BetterC has become rather popular in the D community to simply write programs with the GC disabled. There is a slight divide/debate in the community of what D should be.
I remember trying the full features of D and slowly moving to coding in BetterC to.. eventually.. moving away to another language.
Why?
As much as like Dlang - it tries to be everything. By default it is an OOP, GC language. However, it has functional support, BetterC, as well as (dip1000) Borrow Checker, and others. In the end you end up with programs written in D in various ways. Imagine when using the package manager. You can search for packages.. but how are they implemented? Is it using the GC? Will it work on the latest version o D? So many questions. You end up looking at the code yourself to determine if the library is going to do what you want.
I am not sure if D is a "C++ replacement" today. It tries to compete with orther, modern languages like Rust or Go and others would prefer it to be a C# or Java competitor.
This is why I like Odin. It makes it very clear what it is and isn't. Sure this means that Odin in various ways will have less features than D but atleast I know the code is simpler, and when taking on other Odin projects I know it still follows the same format.
D's scope seems to go far beyond what your average C programmer would want in a language; "use only 15% of the language and you'll be fine" (paraphrasing: "use only the 'better-C' subset", if that is what you meant, and it does seem to be a subset of D) seems a weird proposition; it still complicates things, as in collaboration, idiomatic feel and look of code, the amount of knowledge required to be competent in the language, complexity of a compiler implementation, portability of code etc... and by that logic you'd have to prefer C++ over C as well (since a lot of C is valid C++), or prefer C plus one safety feature added over C; but the "rawness"/limited scope/small size/procedural nature of C is what's appealing for many to begin with.
I for one think that a proper C replacement (C's strength also being the simplicity in which to implement a compiler for example, being the reason it's so ubiquitous in the embedded world) will be a much more limited proposition than D is.
Edit: And having been curious, even "Better-C" still has things many C-programmers wouldn't particularly like. Going by things listed here https://en.wikipedia.org/wiki/D_(programming_language)
RAII
Full metaprogramming
Nested functions, nested structs, delegates and lambdas
Member functions, constructors, destructors, operating overloading, etc.
...
Where to draw the line will be different person to person, but D doesn't seem to be a language "in the spirit of C", or a "modern version of it", at all.Viewing it as a C++ alternative makes much more sense. A `Better-C` "limit yourself to a subset of the language" compiler flag doesn't change that much.
I'd say a couple, not many.
> RAII
Who wouldn't like RAII?
> Metaprogramming
As a way to avoid preprocessor macros? Yes please.
> Nested functions
Already offered as extension.
> Member functions
I'm sure no C programmer would object to that.
> constructors, destructors
This yes. Agreed.
> operating overloading
Instead of _Generic()? Why not?