July 15, 2019
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
> I discussed that briefly on Slack with a couple other developers.
>  My understanding is the `rt` is the language implementation and `core` is the low level library for users.
>
> The code in `rt/array` are language implementations.  They are not to be imported by the user.  They are, however, required by the language to implement D's built-in arrays, so that is why they are publicly imported in object.d.

I think that fits core.internal better than rt. Have you considered that during said discussion?

July 15, 2019
On Monday, 15 July 2019 at 11:49:31 UTC, Vladimir Panteleev wrote:
> On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
>> I discussed that briefly on Slack with a couple other developers.
>>  My understanding is the `rt` is the language implementation and `core` is the low level library for users.
>>
>> The code in `rt/array` are language implementations.  They are not to be imported by the user.  They are, however, required by the language to implement D's built-in arrays, so that is why they are publicly imported in object.d.
>
> I think that fits core.internal better than rt. Have you considered that during said discussion?

For reference, the discussion was this one: http://imgur.com/a/HszdtHd

I'm sorry that I missed it, because Vladimir makes a very good point. rt isn't supposed to be available nor importable by the user. rt can import core, but core can't import rt.
July 15, 2019
On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote:
>> I think that fits core.internal better than rt. Have you considered that during said discussion?

The implementations in `rt/array` contain templates that are ports of runtime hooks that used to reside in `rt`.  The implementations also require importing implementations from `rt` so it makes sense to me that they should all stay within `rt`.

> For reference, the discussion was this one: http://imgur.com/a/HszdtHd
>
> I'm sorry that I missed it, because Vladimir makes a very good point. rt isn't supposed to be available nor importable by the user.

`rt` is not imported by the user; it is imported by the compiler indirectly through `object.d`.

> rt can import core, but core can't import rt.

Many of the implementations in `rt/array` require importing or referencing other implementations in `rt` (e.g. `rt.lifetime`).  If they were moved to `core.internal` they would require importing `rt` or peeking into `rt` with various hacks, which exactly what you've said should not be done.

Based on what you and Vladimir have said, I'm even more confident I've made the right decision putting them in `rt`.

Mike
July 15, 2019
On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote:
> On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote:
>>> I think that fits core.internal better than rt. Have you considered that during said discussion?
>
> The implementations in `rt/array` contain templates that are ports of runtime hooks that used to reside in `rt`.  The implementations also require importing implementations from `rt` so it makes sense to me that they should all stay within `rt`.

You don't need to move the implementations themselves into core.internal. Adding declarations there for the rt implementations would suffice.

> `rt` is not imported by the user; it is imported by the compiler indirectly through `object.d`.

So is the rest of core.internal.

Please take a few minutes to have a look at the contents of the core.internal package, as well as all the places in object.d where modules from core.internal are already imported.

Would you say that those cases are very unlike the case of this particular change? If so, would you mind explaining how?

> Based on what you and Vladimir have said, I'm even more confident I've made the right decision putting them in `rt`.

I really don't see the series of logical steps one would need to take to reach that conclusion.

July 15, 2019
On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote:
> Many of the implementations in `rt/array` require importing or referencing other implementations in `rt` (e.g. `rt.lifetime`).
>  If they were moved to `core.internal` they would require importing `rt` or peeking into `rt` with various hacks, which exactly what you've said should not be done.

This isn't exactly true. The restriction is that core should not *import* rt. Have a look at all the extern(C) definitions in Druntime - using extern(C) functions to communicate between the compiler and rt, as well as core and rt, is not a "hack", but an established mechanism to invoke the low-level implementations in Druntime.

July 15, 2019
On Monday, 15 July 2019 at 12:19:02 UTC, Vladimir Panteleev wrote:

> You don't need to move the implementations themselves into core.internal. Adding declarations there for the rt implementations would suffice.

Many of the implementations in `rt/array` are templates, so the entire implementation should be available through object.d, not just declarations.

> So is the rest of core.internal.
>
> Please take a few minutes to have a look at the contents of the core.internal package, as well as all the places in object.d where modules from core.internal are already imported.
>
> Would you say that those cases are very unlike the case of this particular change? If so, would you mind explaining how?

In `core.internal`, I see utilities that appear to be intended for use only within runtime, or "privately" imported by Phobos.  I do not see implementations for fundamental language features as can be found in `rt`.  The code in `rt/array` implementations for fundamental language features, not utilities to be used privately with druntime.

>> Based on what you and Vladimir have said, I'm even more confident I've made the right decision putting them in `rt`.
>
> I really don't see the series of logical steps one would need to take to reach that conclusion.

"rt can import core, but core can't import rt." makes it pretty clear to me.

Mike


July 15, 2019
On Monday, 15 July 2019 at 12:36:14 UTC, Mike Franklin wrote:
> Many of the implementations in `rt/array` are templates, so the entire implementation should be available through object.d, not just declarations.

The amount of templated code is still finite, otherwise you would have needed to include all of rt into the set of files to be made importable.

> In `core.internal`, I see utilities that appear to be intended for use only within runtime, or "privately" imported by Phobos.
>  I do not see implementations for fundamental language features as can be found in `rt`.  The code in `rt/array` implementations for fundamental language features, not utilities to be used privately with druntime.

Please have a closer look:

- core.internal.hash contains the implementation of hashing routines used for associative arrays.
- core.internal.arrayop contains the implementation of array vector operations. This one doesn't seem to be too far from your work in question.

> "rt can import core, but core can't import rt." makes it pretty clear to me.

Please see my other reply.

July 15, 2019
On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev wrote:

> - core.internal.hash contains the implementation of hashing routines used for associative arrays.
> - core.internal.arrayop contains the implementation of array vector operations. This one doesn't seem to be too far from your work in question.

... and are the exception, not the rule.  I believe they should be moved to `rt`.


July 15, 2019
On Monday, 15 July 2019 at 12:27:22 UTC, Vladimir Panteleev wrote:

> This isn't exactly true. The restriction is that core should not *import* rt. Have a look at all the extern(C) definitions in Druntime - using extern(C) functions to communicate between the compiler and rt, as well as core and rt, is not a "hack", but an established mechanism to invoke the low-level implementations in Druntime.

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`.

Mike
July 15, 2019
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote:
> On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev wrote:
>
>> - core.internal.hash contains the implementation of hashing routines used for associative arrays.
>> - core.internal.arrayop contains the implementation of array vector operations. This one doesn't seem to be too far from your work in question.
>
> ... and are the exception, not the rule.  I believe they should be moved to `rt`.

To what end?

You are supporting a change (and proposing further changes) which breaks existing conventions and solves zero problems, while simultaneously opposing a change that would fix at least two situations that we know of (Digger and Jonathan's installation script).