core.traits?

[Mike Franklin]

On Tuesday, 8 January 2019 at 01:44:08 UTC, Mike Franklin wrote:

> Anyway, my suggestion is to create a new library separate from 
> druntime and phobos that has no dependencies whatsoever (no 
> libc, no libstdc++, no OS dependencies, no druntime dependency, 
> etc.).  I mean it; **no dependencies**.  Not even object.d.  
> The only thing it should require is a D compiler.
>
> That library can then be imported by druntime, phobos, betterC 
> builds, or even the compiler itself. It will take strict 
> enforcement of the "no dependency" rule and good judgment to 
> keep the scope from ballooning, but it may be a good place for 
> things like `traits`, `meta` and others.

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 :/

Mike