On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
>  My understanding is the `rt` is the language implementation and `core` is the low level library for users.

This understanding would be mistaken. We haven't been shipping `rt` on the import path for a long time. `core.internal` exists precisely to fill this role, i.e. code that needs to be around at druntime import time, but isn't supposed to be accessed directly by users.

 — David

On Monday, 15 July 2019 at 19:52:57 UTC, David Nadlinger wrote:
> On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
>>  My understanding is the `rt` is the language implementation and `core` is the low level library for users.
>
> This understanding would be mistaken. We haven't been shipping `rt` on the import path for a long time. `core.internal` exists precisely to fill this role, i.e. code that needs to be around at druntime import time, but isn't supposed to be accessed directly by users.

(Corollary: This should be fixed in a point release to unbreak various tooling and dependent build systems.)

On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
> I'm sorry it broke digger, but digger is not how we typically build DMD, druntime, and Phobos.

It also breaks the LDC build system. Just shipping rt.* too by itself would be simple, but as the frontend takes various libraries when referring to rt symbols internally (using types that don't match, etc.), compiling code that uses certain parts of rt.* at the same time as rt.* itself leads to non-obvious breakage.

The easiest way of making sure this doesn't happen is to just not ship rt.*.

Either way, there is a simple resolution here: Put new template code or other artefacts that are actually used via import in core.* (e.g. core.internal.*). This also provides a natural boundary between legacy code and the new runtime interface. If more and more code gets template-ised, rt.* will slowly wither away, but there is nothing wrong with that. At some point, it will just cease to exist naturally.

 — David

On Monday, 15 July 2019 at 19:41:11 UTC, Johannes Pfau wrote:
> 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.

core.internal.traits.externDFunc takes care of the safety aspect. This is a non-issue. (Interdependencies should be avoided regardless, of course; it is still just a crutch.)

 — David

Am Mon, 15 Jul 2019 20:14:46 +0000 schrieb David Nadlinger:

> On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
>> I'm sorry it broke digger, but digger is not how we typically build DMD, druntime, and Phobos.
> 
> Either way, there is a simple resolution here: Put new template code or other artefacts that are actually used via import in core.* (e.g. core.internal.*). This also provides a natural boundary between legacy code and the new runtime interface. If more and more code gets template-ised, rt.* will slowly wither away, but there is nothing wrong with that. At some point, it will just cease to exist naturally.

Well, I guess if we all agree that rt. is basically deprecated, this may be a good way to move forward.


-- 
Johannes

Am Mon, 15 Jul 2019 19:52:57 +0000 schrieb David Nadlinger:

> On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
>>  My understanding is the `rt` is the language implementation
>> and `core` is the low level library for users.
> 
> This understanding would be mistaken. We haven't been shipping `rt` on the import path for a long time. `core.internal` exists precisely to fill this role, i.e. code that needs to be around at druntime import time, but isn't supposed to be accessed directly by users.
> 
>   — David

I guess this should be documented somewhere then. GDC has always shipped and still ships rt. and never had any problem with that.

-- 
Johannes

On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote:
> I guess this should be documented somewhere then.

See druntime/CONTRIBUTING.md:

```
In general, only modules in the 'core' package should be
made public. The single exception is the 'object' module
which is not in any package.

The convention is to put private modules in the 'rt' or
'gc' packages depending on what they do and only put
public modules in 'core'.

Also, always avoid importing private modules in public
modules. […]
```

This split has been in place since back in the D1/Tango days.

 — David

Am Mon, 15 Jul 2019 20:39:14 +0000 schrieb David Nadlinger:

> On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote:
>> I guess this should be documented somewhere then.
> 
> See druntime/CONTRIBUTING.md:
> 
> ```
> In general, only modules in the 'core' package should be made public.
> The single exception is the 'object' module which is not in any package.
> 
> The convention is to put private modules in the 'rt' or 'gc' packages depending on what they do and only put public modules in 'core'.
> 
> Also, always avoid importing private modules in public modules. […] ```
> 

Well, this just opens the discussion on private vs. public modules again. The new array hooks are private as well, according to the definition above they would have to be in rt. And core.internal.* certainly aren't public modules.

I don't see how "should be made public" can be interpreted as "should be installed", especially considering that templates need source code installed (core.internal), but that's completely orthogonal to what functions should be private (core.internal) / public to users of druntime.

However, I'll open a PR to clarify that paragraph.



> This split has been in place since back in the D1/Tango days.

Sure, the core vs rt split did. But core.internal did not exist in D1.

-- 
Johannes

On Monday, 15 July 2019 at 20:57:59 UTC, Johannes Pfau wrote:
> I don't see how "should be made public" can be interpreted as "should be installed", especially considering that templates need source code installed (core.internal), but that's completely orthogonal to what functions should be private (core.internal) / public to users of druntime.
>
> However, I'll open a PR to clarify that paragraph.

Yes, clarifying that paragraph is a good idea. The intended meaning used to be unambiguous especially given this part:

"If a public module consists of a header file and an implementation file (which are both maintained by hand) then it is OK to import private modules in the implementation file."

This refers to the fact that some modules (object, core.thread) used to have hand-written .di files to separate the public interface from the implementations (which made use of rt.* imports).

Now that those duplicate .di files have (fortunately!) been done away with, I can see how the wording could be unclear without that prior knowledge. And in either case, avoiding to use heavily overloaded terms ("private"/"public") without further explanation is a good idea.


>> This split has been in place since back in the D1/Tango days.
>
> Sure, the core vs rt split did. But core.internal did not exist in D1.

How core is organised internally has little do with whether rt is public or not.

 — David

On Monday, 15 July 2019 at 19:56:29 UTC, David Nadlinger wrote:
> (Corollary: This should be fixed in a point release to unbreak various tooling and dependent build systems.)

Fortunately, these changes still have not appeared in a release, so we can still fix them. The reason why this discussion occurred in this thread was that a Digger user tried to install the "master" version after a stable release, at which point the change had already occurred in the master branch.

https://github.com/dlang/druntime/pull/2681