What would a minimal subset of D look like?

[Ola Fosheim Grøstad]

On Saturday, 22 June 2019 at 10:10:13 UTC, Mike Franklin wrote:
> Interfaces are an obvious one to me.  They can be implemented 
> using D's introspection features, and in some cases they aren't 
> even really necessary.  See this discussion on the topic:  
> https://forum.dlang.org/post/qndhfzrnipsnvsstrdvg@forum.dlang.org

Yes, static interfaces can be done by duck-typing and 
conventions.  Although it is difficult to ensure type safety with 
duck-typing alone (but one can improve on that with an enum that 
says something about capabilities and test those with a static 
assert).


> Classes are another.  See 
> https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html for a very interesting implementation of class-like behavior without classes.  I think D may need additional features to make it work seamlessly without language support, but you can get pretty far today.

Hmm, yes, that wasn't very clean... I guess this is a good 
argument for providing AST manipulation features ("AST macros").


> I'm quite convinced that if we added `opImplicitCast` to the 
> language, we could implement `alias this` and multiple `alias 
> this` in the language.  There was a recent discussion about 
> that too: 
> https://forum.dlang.org/post/ozdjozskgwqxfykijrsh@forum.dlang.org

Hmm, yes, but if one is forced to resort to using string 
concatenation in a macroish fashion then I think that would be a 
sign of a missing language feature or that the meta programming 
capabilities need improvement.

Although, perhaps the argument you are making is that "alias 
this" is not really needed, but if you absolutely need it one 
time, then it is possible?  Like an "escape-hatch"?


> I have a few others, but I think those examples illustrate the 
> general idea.  Basically, I'd double-down on the introspection, 
> metaprogramming, and compile-time features of D, and then use 
> those features to implement whatever features one needs.

Yes, that seems reasonable, as long as it doesn't harm the type 
system and the bugs that a strict type system can catch.

That is one of the issues that can arise with very generic 
template based code, that it can easily accept anything with no 
warning.


>  Some are concerned about falling for the Lisp curse 
> (http://winestockwebdesign.com/Essays/Lisp_Curse.html), but I 
> think it can be done tastefully to avoid that.

I don't really think this necessarily is an issue for 
embedded/low level systems programming if you have "LISP"-like 
coding features limited to libraries in the same way D now does 
with @safe.

I don't think low level programmers will absorb badly written 
libraries in the same way that people do in some high level 
contexts (javascript *coughs*).