Splitting std.typecons [Was: Re: RFC: std.sumtype (adding sumtype to Phobos)]

[Paul Backus]

On Wednesday, 25 November 2020 at 16:50:53 UTC, Petar Kirov 
[ZombineDev] wrote:
>
> Well, perhaps `tuple` is a clear enough name, and it could 
> stand on its own, but what about things like BlackHole?

For the parts that don't stand on their own, we can either leave 
them in std.typecons, extract related subsets into new modules as 
a group, or find them new homes in existing modules.

> For me the reasons for the nesting are:
> * (subjective) it looks better organized and aesthetically 
> pleasing to put related modules under a single package. Even if 
> I would design the module structure from scratch, I'd still put 
> `tuple` under `typecons` (or e.g. `algebraic` / `adt`, along 
> with `sumtype`).

I think it *can* be useful to group related modules together in a 
single package, so long as

1) The modules are actually related.
2) The grouping conveys some useful information that a standalone 
module would not.

Most of the parts of std.typecons fail to satisfy criterion #1; 
for example, there is no particular relationship between 
`Nullable` and `BitFlags`. Meanwhile, your hypothetical 
`std.adt.tuple` and `std.adt.sumtype` fail to satisfy criterion 
#2: if you know what a "tuple" and a "sumtype" are, you either 
know that they are ADTs, in which case the package name "adt" 
doesn't tell you anything new, or you don't know what an ADT is, 
in which case the package name "adt" tells you nothing at all.

While I understand that aesthetic judgement is subjective, I 
don't think it's really justifiable to make decisions about a 
widely-used project like a standard library based on gut feeling 
alone. The goal in naming a module (or a type, a function, a 
variable, etc.) is to communicate information to its users, after 
all, not to satisfy our own personal preferences.

> * After the split, existing users won't have troubles (however 
> small) finding the modules as they would remain grouped under 
> their original `typecons` parent

The solution to this is to add links to each publicly-imported 
module to std.typecons' documentation--i.e., the same thing we 
already do for std.range and std.algorithm.

> * Nothing to deprecate -> no future breaking changes

There is no need to deprecate anything in either case. Even if 
std.typecons is completely hollowed out, there is no reason it 
cannot remain present for backwards compatibility indefinitely.