D as a betterC a game changer ?

[bpr]

On Sunday, 24 December 2017 at 10:57:28 UTC, Mike Parker wrote:
> The motivation behind the -betterC flag is *not* to write new 
> programs in the general case.

Whether you agree or not, that is *exactly* how some programmers 
would like to use it. I think that's a good thing, and I hope 
lots of other people do too, and start writing lots of betterC 
code. Let a thousand flowers bloom.

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

If you think that GCs suck, or at least, that the D GC sucks, 
then D doesn't fare well in the comparison with C++. Rust might, 
by that criteria.

I'd have preferred not to have worded it that way, since I don't 
think GCs suck in general, but it seems there's a big failure to 
communicate between different camps of programmers, which affects 
D more than other languages since it is intended to be a very 
general purpose language, much like C++. GC is not an unqualified 
positive

> 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.

That's great!

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

In general, GCs and runtimes don't compose well, so if you write 
a D library that you want to be called from a language with its 
own GC and runtime, that's yet another hoop to jump through. Go 
might be a better C for some people, but extending Python with Go 
libraries hasn't caught on. New D libraries written as betterC 
handle this case.