How important is it to avoid circular dependencies in Phobos?

I'm wondering because I have divided my work-in-progress std.checkedint module into various submodules to make it easier for people to import only the part they actually want to use.

However, most of these submodules depend at least a little bit on all the others. This comment by Walter Bright makes me wonder if the current layout would be accepted:

http://forum.dlang.org/post/n6alnb$226t$1@digitalmars.com
> Circular declarations are one thing, circular modules are another. Phobos suffers from circular modules, and I'd like to refactor them out.

Would my submodule scheme be likely to pass review, or should I just change it now?

On Sunday, 3 January 2016 at 15:46:55 UTC, tsbockman wrote:
> How important is it to avoid circular dependencies in Phobos?
>
> I'm wondering because I have divided my work-in-progress std.checkedint module into various submodules to make it easier for people to import only the part they actually want to use.

Splitting modules into a circular package retains *some* of the benefits of split modules, like the smaller namespace in importing modules: while the whole tree is recursively pulled in, the user chooses which symbols to make available in the importing module. In D we have a number of conflict resolution mechanisms, including selective imports, so I don't count this as particularly useful.

The real benefits come when the split modules form a clean, non-circular dependency graph. Then we get the good stuff like faster compile times and smaller executables, can be understood in chunks etc.

I'm personally not a fan of circular modules, but I don't have strong opinions about them. In Phobos we have a number of modules with poor granularity that could be split into clean dependency trees. I don't know what to do, if anything, about circular modules that *can't* reasonably be split up as such.

On Sunday, 3 January 2016 at 16:52:28 UTC, Jakob Ovrum wrote:
> In D we have a number of conflict resolution mechanisms, including
> selective imports, so I don't count this as particularly useful.

That would be more helpful if selective imports weren't semi-banned at the top level:
    https://github.com/D-Programming-Language/dmd/pull/3407
Hopefully that will finally get merged before checkedint is ready...

On Sunday, 3 January 2016 at 16:55:50 UTC, tsbockman wrote:
> That would be more helpful if selective imports weren't semi-banned at the top level:
>     https://github.com/D-Programming-Language/dmd/pull/3407
> Hopefully that will finally get merged before checkedint is ready...

It's only a relevant issue for library code.

On Sunday, 3 January 2016 at 17:09:45 UTC, Jakob Ovrum wrote:
> On Sunday, 3 January 2016 at 16:55:50 UTC, tsbockman wrote:
>> That would be more helpful if selective imports weren't semi-banned at the top level:
>>     https://github.com/D-Programming-Language/dmd/pull/3407
>> Hopefully that will finally get merged before checkedint is ready...
>
> It's only a relevant issue for library code.

Surely checkedint should be usable from library code, though.

On Sunday, 3 January 2016 at 17:13:34 UTC, tsbockman wrote:
> On Sunday, 3 January 2016 at 17:09:45 UTC, Jakob Ovrum wrote:
>> On Sunday, 3 January 2016 at 16:55:50 UTC, tsbockman wrote:
>>> That would be more helpful if selective imports weren't semi-banned at the top level:
>>>     https://github.com/D-Programming-Language/dmd/pull/3407
>>> Hopefully that will finally get merged before checkedint is ready...
>>
>> It's only a relevant issue for library code.
>
> Surely checkedint should be usable from library code, though.

Yes, but it shouldn't be designed around a bug.

On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:
> Yes, but it shouldn't be designed around a bug.

Unless the bug is actually going to be fixed some time soon, why would I deliberately design something in a way that is broken? Does it really matter *why* it is broken?

On Sunday, 3 January 2016 at 17:25:40 UTC, tsbockman wrote:
> On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:
>> Yes, but it shouldn't be designed around a bug.
>
> Unless the bug is actually going to be fixed some time soon, why would I deliberately design something in a way that is broken? Does it really matter *why* it is broken?

So, we're talking about a library using CheckedInt. If the library selectively imports anything from CheckedInt at module-level, it'll always be public due to a bug.

This is trivial to work around. Often the import can be nested, and when it can't, a static import or renamed module import can be used to resolve conflicts.

It's not a big deal.

On Sunday, 3 January 2016 at 17:31:41 UTC, Jakob Ovrum wrote:
> On Sunday, 3 January 2016 at 17:25:40 UTC, tsbockman wrote:
>> On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:
>>> Yes, but it shouldn't be designed around a bug.
>>
>> Unless the bug is actually going to be fixed some time soon, why would I deliberately design something in a way that is broken? Does it really matter *why* it is broken?
>
> So, we're talking about a library using CheckedInt. If the library selectively imports anything from CheckedInt at module-level, it'll always be public due to a bug.
>
> This is trivial to work around. Often the import can be nested, and when it can't, a static import or renamed module import can be used to resolve conflicts.
>
> It's not a big deal.

Apparently the bug affects static imports and renamed module imports too. Bleh.

On Sunday, 3 January 2016 at 17:34:19 UTC, Jakob Ovrum wrote:
> On Sunday, 3 January 2016 at 17:31:41 UTC, Jakob Ovrum wrote:
>> On Sunday, 3 January 2016 at 17:25:40 UTC, tsbockman wrote:
>>> On Sunday, 3 January 2016 at 17:18:05 UTC, Jakob Ovrum wrote:
>>>> Yes, but it shouldn't be designed around a bug.
>>>
>>> Unless the bug is actually going to be fixed some time soon, why would I deliberately design something in a way that is broken? Does it really matter *why* it is broken?
>>
>> So, we're talking about a library using CheckedInt. If the library selectively imports anything from CheckedInt at module-level, it'll always be public due to a bug.
>>
>> This is trivial to work around. Often the import can be nested, and when it can't, a static import or renamed module import can be used to resolve conflicts.
>>
>> It's not a big deal.
>
> Apparently the bug affects static imports and renamed module imports too. Bleh.

Yes visibility control for the import system is pretty badly broken right now. I'm surprised this still hasn't been fixed after so long; I guess it must be really tricky for some reason.

Anyway, my submodule setup is motivated as much by the desire not to be forced to make long lists of every symbol I import, as it is by the need to work around that bug. If it was left up to me, my scheme wouldn't change that much even if the bug were fixed tomorrow.