On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote:
On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky
(Abscissa) wrote:
First of all, betterC is about far more than interfacing with
C. In fact, interop with C isn't really what betterC is about
at all - that's a separate aspect of the language. (And those
C/C++ users who still haven't come to D - for many of them the
holdout is *because* of the issues betterC aims to address.
What is that issue? Runtime? It can be solved with minimal
runtime that one can write in an evening, compare it to betterC
effort that has no end in sight.
Make no mistake, for all the stockholm syndrome in the C and
C++ worlds, there *are* a lot people openly wanting to jump
ship but don't have a sufficient option yet.
I'm afraid a sufficient option for them is proper C++ superset,
betterC is only the first excuse, but not last.
Personally, better DLL support have little to no impact on me.
Obviously it does for you, and I sympathise.
FWIW DLL support was always good enough for me.
It is much more than runtime or no runtime.
First of all, that goal (better interoperability) has been on the
foundation priority list for several years, it is about time to
"finish it up".
You have to remember that the really big first client of
betterC(++) was DMD, porting DMD from C++ was a big undertaking.
Right now both DMD and LDC use a form of betterC, so it is
critical to have it finalized.
Second, it is a really good tool for validating a constraint
environment, running D code with minimal runtime and compiler
guarantees is very good thing to have in a system level
programming language.
Third, since it was introduced, it really helped better
abstracting compiler internals and removing dependencies between
compiler and runtime. People don't solve problems they don't
have, hence introducing a new restriction added some stress that
shaped a better version of D. As stated, D is a *system level
programming language*, this means that ultimately needs to offer
tools for embedded developers and OS kernel driver writers.
betterC is one of those tools, and ultimately is part of the
philosophy of pay-as-you-go, or a driving force to be better at
it. Also, I think it fits nicely into "turtles all the way down"
approach, as it makes the language orthogonal and more glued
together vs. offering some vague advice on how to approach
constraint systems, it provides rules and methods of enforcement.
Lastly, the objective is a bit vague - there is no scope attached
to it, maybe this needs clarifications. Even if it means fixing
all the logged bugs related to it, it is a great step, at least
for me.
