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

[Mike Franklin]

On Thursday, 23 May 2019 at 06:16:08 UTC, Manu wrote:
> I noticed a bizarre situation just now; while DMD has magic in 
> the compiler to understand ranges and lower foreach loops to 
> call range primitives and such, the material to determine any 
> range API is not available to druntime, it's all the way out in 
> std.range.primitives.
>
> Why is there no core.range with said primitives in it? I think 
> it's fine that chain and zip and iota all that jazz is in 
> phobos, but surely isInputRange, isRandomAccessRange, 
> hasLength, etc should all be in the lowest level runtime 
> possible?

I think Andrei said it best here:  
https://forum.dlang.org/post/q7j4sl$17pe$1@digitalmars.com

---
> Oh, and druntime must go.
> 
> The whole distinction between the runtime library and the 
> standard library is clowny and has more to do with poorly 
> ported tradition from other languages, than with anything else.
> 
> We need one standard library that is entirely pay-as-you-go 
> (e.g. empty main() means no library file is ever needed for 
> linking) and that offers an opt-in continuum.
---

So, the divide between druntime and phobos shouldn't even exist.  
But what does a united druntime/Phobos look like?  How do we 
organize it logically, and modularly with clear boundaries, so it 
doesn't turn into a tangled mess and users only pay for what they 
use?  I don't know, but I'm trying to figure that out.

Andrei and I have a difference of opinion on how to achieve that 
which is apparent in this conversation:  
https://github.com/dlang/dmd/pull/9814  I'm trying to engage with 
him via e-mail and other PRs (e.g. 
https://github.com/JinShil/utiliD/pull/7) to incrementally work 
something out and get a clearer vision of what the future should 
look like.

There are also some prerequisites that need to be implemented 
first before some of this stuff will work right (e.g. converting 
some runtime hooks to templates).  That's also being worked on.

> It's kinda the same deal as those select traits which are 
> practically part of the language, they don't generate any code, 
> and it's virtually impossible to do anything useful without 
> them.
>
> Should they be moved?

For now, yeah, perhaps they should just be moved to `core.range` 
or something like that until a better vision of what a united, 
pay-as-you-go druntime/phobos is worked out.

I'm mentoring a GSoC project this year and we could actually 
benefit from having some of that range stuff in druntime.

And this isn't unique to the range stuff.  There's quite a bit in 
Phobos (std.traits, std.conv, std.meta, etc...) that really needs 
to be available to all D programs including druntime and the 
compiler itself.

Mike