A Case for Oxidation: A potential missed opportunity for D

[kinke]

On Friday, 29 June 2018 at 11:31:17 UTC, Radu wrote:
> There technical and political reason here.
>
> BetterC offers a clean no-overhead strictly enforced subset of 
> the language. This is great for porting over existing C code 
> base and also for creating equivalent libs in D but without 
> worrying that you carry over baggage from the D run-time.
>
> It also serves as a good tire 1 target when porting D to other 
> platforms. WebAssembly is one of those odd platforms were D 
> could shine, and having betterC greatly easy the effort of 
> porting it over (even though so far nobody stepped out to do 
> this).
>
> C is a beast and its hardcore programmers will not touch 
> anything that has typeinfo, gc or classes. Selling betterC to 
> them (this includes teammates) is a lot easier, you can show 
> them the assembly on godblot.org and they see no extra fat is 
> added. @safe is the added bonus and the final nail in the 
> coffin to ditch C.
>
> But ultimately betterC is also a sign of the design failure on 
> both dlang and druntime in the way that it wasn't conceived to 
> be modular and easier to use in a pay-as-you-go fashion. Until 
> the GC and typeinfo is truly optional and reserved only for the 
> top layers of the standard library betterC is the best we have.

Okay, thanks for the rationale. If it's mainly about 
Type-/ModuleInfos bloat and the GC, the compiler fed with 
-betterC could also

* continue to elide the Type-/ModuleInfo emission,
* additionally error out on all implicit druntime calls to the GC,
* still link in druntime and Phobos.

That should make more things work, incl. the above slice copy and 
(manually allocated) extern(C++) classes.