Release D 2.087.0

[Johannes Pfau]

Am Mon, 15 Jul 2019 14:00:23 +0000 schrieb Mike Franklin:

> On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
> 
>>> We are trying to implement many of those `extern(C)` runtime hooks as
>>> templates.  Those templates need to be implicitly imported through
>>> object.d.  That means code that was in `rt` is converted to a
>>> template, and then moved to object.d. However, as we do more and more
>>> of them object.d becomes unwieldy.
>>>
>>> I took the initiative to prevent object.d from turning into a more of
>>> a monstrosity that it already is, and moved those runtime templates
>>> (which used to reside in `rt`) back into `rt`.
>>
>> This is not a problem, and not at all related to the issue we're
>> discussing. The problem is that you chose to move them into `rt`
>> instead of somewhere under `core`, which would respect existing
>> conventions and avoid breakages like the ones we've seen reported in
>> this thread.
> 
> It is related.  If I follow your suggestion to move these
> implementations to `core.internal` and continue with the objective of
> converting all runtime hooks to templates, the vast majority of `rt`
> will end up being moved to `core.internal`.  Is that what you're
> suggesting?
> 
> `rt` is the language implementation.  `core.internal` contains the
> utilities used internally by druntime and "privately" imported by
> Phobos.  Following that established convention, I made the right
> decision.
> 
> I'm sorry it broke digger, but digger is not how we typically build DMD,
> druntime, and Phobos.
> 
> Mike

I agree here: rt is code deeply tied to the language / compiler. 
core.internal is largely code which is useful as standalone module 
(abort, convert, parts of dassert, lifetime, traits, string).

However, the structure is not really clear: rt.util (older than 
core.internal) should probably rather be part of core.internal and some 
code in core.internal (arrayop, assert) should be in rt.

Either way, dictating a code structure on druntime only because of build 
system aspects (these files are installed, these are not) seems to be a 
very bad idea. The code should be structured in a way to minimize cross-
module dependencies and to seperate compiler specific from generic code.

In addition, the build system shipped as part of druntime is the 
authoritative way to build the project. Even though digger is an 
important tool, we can't really compromise on code quality in druntime 
only to stay compatible to build systems using undocumented internals of 
the runtime build process.

-- 
Johannes