DMD supports ranges, but druntime can't see them?

[Mike Franklin]

On Thursday, 23 May 2019 at 09:46:14 UTC, Timo Sintonen wrote:

> We actually do need a runtime library. It should contain code 
> for compiler generated runtime function calls. Nothing else.

I agree. But consider that that runtime library is also written 
in D, and can have some complex constructs.  That is why I want 
to build something like utiliD, so it can be imported by that 
runtime library and used to make the runtime library's 
implementation more idiomatic D.  It can also be used by 
applications that aren't using any runtime features (e.g. some 
bare-metal platforms, and consuming D libraries from other 
languages such as C).

> Users should have no need to import it or even have access to 
> it.

This is where I disagree because I'm trying to make the language 
opt-in and pay-as-you-go.  What I'm envisioning is a "Language as 
a Library".  If one wants classes they `import classes;`.  If one 
wants exceptions, they `import exceptions;` etc.  The modules one 
imports contain the compiler lowerings and other constructs to 
support the feature.  The compiler will emit an error if it can't 
find something that's not imported, including the compiler hooks, 
(just like it does today if one tries to use a symbol that isn't 
imported)  Users opt-in to a feature by importing the feature.  
Note that this behavior is predicated on work being done to move 
all runtime lowerings into the semantic phase of the compiler 
instead of the IR stage like it is today.  That work is currently 
underway.

Walter and Andrei don't appear to like that idea.  What they 
appear to propose is to make *all* runtime constructs templates.  
The runtime library is automatically imported, but because it's 
all templates, there's nothing to link.  Users opt-in to a 
feature by simply using it.  Either the instantiate one of the 
runtime templates explicitly, or by using the feature, the 
compiler lowers an expression to a runtime template implicitly.

I'm skeptical of that.  For example, do we need to declare `class 
Object() {}` instead of `class Object {}` in the runtime template 
library?  And think how that would need to scale all the way down 
the call stack if each runtime implementation, and constructs it 
uses, and each construct that those constructs use all need to be 
templated.  And what would that do to compile-times? Each module 
would have to re-compile all the runtime stuff they utilize.  And 
what about the potential for template bloat?

Mike