What would a minimal subset of D look like?

[Ola Fosheim Grøstad]

On Saturday, 22 June 2019 at 09:57:30 UTC, Mike Franklin wrote:
> I could get by with structs, basic types, functions, and 
> typical flow-control features of any language.  I wouldn't 
> enjoy it, though, for anything complex.

Yes, even though the goal is to find a minimal language subset, 
the resulting language shouldn't feel limiting.

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?

> So the features I would prefer would probably depend greatly on 
> the complexity of the project I was working on and the resource 
> constraints of the platform.

Yes, available memory is also growing on embedded platform.


> That is why I think the opt-in continuum 
> (https://forum.dlang.org/post/q7j4sl$17pe$1@digitalmars.com) 
> that Andrei mentioned a while back is so important.  It allows 
> one to scale up with the complexity of the project and/or the 
> available resources of the platform.

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.

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.

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.