core.traits?

[Jacob Carlborg]

On 2019-01-08 06:37, Mike Franklin wrote:

> I spent some time trying to think through some of the issues with 
> druntime, and came up with this:
> 
> Right now, druntime is somewhat of a monolith trying to be too many things.
>    * utilities (traits, string utilities, type conversion utilities, 
> etc...)
>    * compiler lowerings
>    * C standard library bindings
>    * C++ standard library bindings
>    * C standard library bindings
>    * Operating system bindings
>    * OS abstractions (thread, fibers, context switching, etc...)
>    * Compiler lowerings
>    * DWARF implementation
>    * TLS implementation
>    * GC
>    * (probably more)
> 
> So, I suggest something like this:
> ----------------------------------
> * core.util - a.k.a utiliD - Just utility implementations written in D 
> (e.g `std.traits`, `std.meta`, etc. No dependencies whatsoever. No 
> operating system or platform abstractions. No high-level language 
> features(e.g. exceptions)
>      * public imports: (none)
>      * private imports: (none)
> 
> * core.stdc - C standard library bindings - libc functions verbatim; no 
> convenience or utility implementations
>      * public imports: (none)
>      * private imports: core.util
> 
> * core.stdcpp - C++ standard library bindings - libstdc++ data 
> structures verbatim; no convenience or utility implementations
>      * public imports: (none)
>      * private imports: core.util
> 
> * sys - OS/Platform bindings - operating system implementations 
> verbatim; no convenience or utility implementations
>      * public imports: (none)
>      * private imports: core.util
> 
> * core.pal - Platform/OS abstractions - threads, fibers, context 
> switching, etc.
>      * public imports: (none)
>      * private imports: core.util, sys, core.libc
> 
> * core.d - compiler support (compiler lowerings, runtime initialization, 
> TLS implementation, DWARF implementation, GC, etc...)
>      * public imports : core.util
>      * private imports : core.pal
> 
> * druntime - Just a top-level package containing public imports, 
> aliases, and compiler support. No other implementations
>      * public imports: core.pal, core.d
>      * private imports: core.util
> 
> * std - phobos
>      * public imports: (none)
>      * private imports: druntime
> 
> There are likely other suitable ways to organize it, but that's just 
> what I could come up with after thinking through it a little.
> 
> I would prefer if each of those were in their own repository and even 
> move some of them to Deimos or dub, but that would probably irritate a 
> lot of people.  I'd also prefer to have each of those in their own 
> packages, but D is probably too deep in technical debt for that.  (See 
> also https://issues.dlang.org/show_bug.cgi?id=11666)
> 
> So, to make it more palatable, I suggest:
> -----------------------------------------
>    * `core.util` gets own repository so it can be independently added to 
> other repositories as a self-contained/freestanding dependency
> 
>    * `core.stdc`, `core.stdcpp`, `sys`, `core.pal`, and `core.d` all go 
> into the druntime monolith like it is today.
> 
>    * phobos remains much like it is today.
> 
> In the context of the discussion at hand, `std.traits`, `std.meta`, and 
> other utilities can be moved to `core.util`. `core.util` can then be 
> added as a dependency to dmd, druntime, and phobos.  The rest will 
> probably have to wait for D3 :/

I like this approach.

-- 
/Jacob Carlborg