On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis
I confess that I tend to think of betterC as a waste of time.
Clearly, there are folks who find it useful, but it loses so
much that I see no point in using it for anything unless I have
no choice. As long as attempts to improve it don't negatively
impact normal D, then I don't really care what happens with it,
but it's clearly not for me.
And it _is_ possible to use full-featured D from C/C++ when D
does not control main. It's just more of a pain.
I'm somewhat in agreement here. I wouldn't call it a "waste of
time", but I would prefer refactoring D's implementation to make
using full-featured D from C/C++ less of a pain. I fear,
however, that -betterC will be the favored excuse for not
pursuing or prioritizing such improvements.
Consider this: Rust doesn't need a special switch to make it
interoperable with C. What's wrong with D's implementation that
requires such things? Granted, D is not Rust, but D's
implementation could be improved to make it more competitive with
Rust in these use cases. For example, there is really no need
for TypeInfo if you're not doing any dynanmic casts, but the
current implementation generates it regardless. I find -betterC
to be somewhat of a copout for avoiding the hard work of
improving D's implementation.