from my perspective it makes sense to split a module M into submodules A, B when: * M is large * there's little interaction between A and B (eg only few symbols from A are needed in B and vice versa) * A and B are logically grouped (that is domain specific) * it doesn't turn into an extreme (1 function per module)
Advantages of splitting: * easier to review * easier to edit (no need to scroll much to see entirety of module we're editing) * less pollution from top-level imports as they only affect submodule (likewise with top-level attributes etc) * more modular * doesn't affect existing code since `import M` will continue to work after M is split into a package * less memory when using separate compilation * allows fine-grained compiler options (eg we can compile B with `-O` if needed) * allows to run unittests just for A instead of M * allows selective import in client to avoid pulling in too many dependencies (see arguments that were made for std.range.primitives) Disadvantages of splitting: * more files; but not sure why that's a problem so long we don't go into extremes (eg 1 function per module or other things of bad taste) --- while working on https://github.com/dlang/phobos/pull/6178 I had initially split M:std.array into submodules: A:std.array.util (the old std.array) and B:std.array.static_array (everything added in the PR) IMO this made sense according to my above criteria (in this case there was 0 interaction between A and B), but the reviewers disagreed with the split. So, what are the guidelines?