Release D 2.087.0

[Johannes Pfau]

Am Mon, 15 Jul 2019 17:59:25 +0000 schrieb Seb:

> On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
>> 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
> 
> The point is that we don't ship the sources of rt to the user. That's
> the separation. With templates sources must be made available to the
> user, s.t. the compiler can instantiate them. However, rt doesn't get
> shipped to the user as it is compiled only.
> 

But why is that? What's the benefit here? And do we skip to this 
convention forever, only for legacy reasons?
We always shipped rt in gdc btw. Nobody ever complained.


If we decide to move that code to core.internal, I'm with Mike that we 
should simply move all array code out of rt. In the long term, we may 
even end up moving anything out of rt: Modern D code is template heavy, 
template code needs the sources available. Inlining needs the sources as 
well. The more we get rid of TypeInfo and the more we modernize the 
compiler/runtime interface, this weill become an issue.

And duplicating extern(C) declarations, syncing them manually, ... is a 
safety liability and maintainance nightmare (see my other post). So in no 
way should we start to add more such functions interfacing rt to 
core.internal.


-- 
Johannes