Vision document for H1 2018

[Radu]

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.