What would a minimal subset of D look like?

[Mike Franklin]

On Saturday, 22 June 2019 at 10:22:10 UTC, Ola Fosheim Grøstad 
wrote:

> So does this mean that things like lacking runtime-resolved 
> virtual functions will feel limiting? Or would statically 
> resolved virtual functions be enough, or is not having virtual 
> functions ok if you have some other feature like interfaces?

I think that's a good point. In the embedded systems that I've 
programmed, so much is known statically, at compile-time, so I 
just don't really have much need for many runtime features.  
However, some embedded systems today are much more powerful than 
PC of the 1990's, and include 2D graphics and such.  I might 
prefer more runtime features in a scenario like that, but I think 
I could probably get by without them, especially since you other 
ways to dynamically dispatch.


> Yes, I believe that also was the goal of Rust, to have close to 
> no runtime library.
>
> However I think one might distinguish between 
> type-system-mechanisms and features that are necessary for code 
> generation and those that are only for verification and testing.
>
> For instance, I am not convinced that features that enable the 
> Rust borrow checker has to be part of the language.  But I 
> haven't given that a lot of thought.  It seems like it could be 
> done with as library types, with annotations, and an external 
> static analysis pass.

I've been wondering about that too.  I think D's lifetime 
annotations (scope and return) get you pretty far, but D still 
allows two mutable references to one object.  It'd be nice to 
have some control over that in D.

> Similarily, there is no need for unittests to be a language 
> feature in D. You can achieve the same with annotations and an 
> external pass.

Agreed. It's mostly a convenience because it allows you to place 
the test locally next to the implementation.

> More importantly, if a language is kept minimal, with solid 
> meta programming and annotation capabilities, then you can 
> increase the opt-in-continuum by integrating external tooling.

Agreed, but I would prefer library features over tooling.

Mike