Vision document for H1 2018

[Joakim]

On Sunday, 18 March 2018 at 10:28:58 UTC, Radu wrote:
> On Friday, 16 March 2018 at 18:15:02 UTC, David Nadlinger wrote:
>> On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:
>>> 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.
>>
>> This is entirely wrong. DMD and LDC rely extern(C++), but this 
>> has nothing to do with -betterC whatsoever.
>>
>> Both compilers link and initialise the runtime as normal (and 
>> then disable the GC at runtime).
>>
>>  — David
>
> I stand corrected. I remembered something about druntime being 
> used but last time I checked front end code was filled with 
> strcpm and strlen, wrongly assumed that druntime was not used. 
> Oh well...

You're not completely wrong about this: the dmd frontend uses 
almost nothing from druntime, not counting extern(C) declarations 
that are really from the local libc, and nothing from Phobos. 
However, I think it still requires druntime to be linked against 
because of some compiler-generated symbols and the like.  Also, 
LDC using the D frontend has allowed a few Phobos dependencies to 
creep in.

So where you were wrong is in saying dmd/ldc use betterC, which 
is an extreme that precludes linking against druntime or Phobos 
at all, though you could still use extern(C) declarations alone 
from the stdlib. What you may have been thinking of is Walter's 
plan to move the dmd backend to D written with betterC, because 
he'd like to use that same D backend with his C/C++ compiler 
frontends written in C/C++ and he wants to dogfood betterC there.

You weren't wrong that the dmd frontend is very much written in a 
betterC style, it just isn't fully usable with betterC yet.

> Still, probably D compilers will benefit from fixing mangling 
> bugs and allow more integration with C++ std, right?

Sure, David was simply pointing out that the betterC and 
extern(C++) efforts are orthogonal and that one doesn't imply the 
other: the ddmd frontend is an example of this, extensively using 
extern(C++) but not enabling betterC.