D as a betterC a game changer ?

[Mike Parker]

On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:
>
> It is a game chager for D, or a least huge step forward  but 
> what is the killer feature against a betterC done through C++ + 
> STL ? Can anyone who really know both D and C++ godlike say why
>  D as betterC and not C++ as better C? Maybe Andrei or Walter ?
>

The motivation behind the -betterC flag is *not* to write new 
programs in the general case. It's to make it a whole lot easier 
to a) port existing C code to D and b) enable D code to be used 
in places where one might otherwise use C. That's hard to do with 
the full range of D features because of the dependency on 
DRuntime. By taking away that dependency and treating D solely as 
a "better C", it becomes much easier.

For example, say you have a program written in C that you'd like 
to port to D. With -betterC, you can move each function into a D 
module one at a time, compile to an object file and link in to 
the program without worrying about linking in DRuntime or 
creating your own object.d stub. Your program continues to work 
just as if it were sill all in C. Then, once the program is 
ported you can start refactoring it to use regular D features. 
This approach reduces the chance for errors and makes it easier 
to ensure the program works as it always has.

 From that perspective, comparing "D as a better C" to C++ is not 
appropriate. Comparing regular D (without -betterC) to C++ makes 
more sense.

That said, some things that currently are not supported in 
-betterC mode may be in the future. For example, the upcoming 
2.078.0 release will add RAII support (including scope(exit))[1] 
to -betterC mode. Future versions might support exception 
handling of some kind.

But for new code, D is already a better C without the -betterC 
flag.

https://dlang.org/changelog/2.078.0.html#raii