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

[Petar]

On Wednesday, 25 November 2020 at 16:22:31 UTC, Paul Backus wrote:
> On Wednesday, 25 November 2020 at 16:02:01 UTC, Petar Kirov 
> [ZombineDev] wrote:
>>
>> FWIW, I'd prefer not to split `std.typecons` into independent 
>> modules like `std.tuple`, `std.nullable`, `std.unique`, etc., 
>> but as as a package containing those modules: 
>> `std.typecons.tuple`, `std.typecons.nullable`, 
>> `std.typecons.unique`. So sumtype could continue to leave in a 
>> single module, but under the `std.typecons` package: 
>> `std.typecons.sumtype`. A few years ago we split std.algorithm 
>> like that and this didn't breaking any existing code as far as 
>> I remember, as we used `public import`s for backward 
>> compatibility.
>
> I just don't see any reason for the extra level of nesting. The 
> module name `std.typecons.tuple` doesn't convey any more 
> information than `std.tuple`. Are we saving the name 
> `std.tuple` for something else? Are we planning on having 
> multiple `tuple` modules in Phobos, such that we'll need to 
> distinguish between `std.typecons.tuple` and 
> `std.something_else.tuple`?
>
> We can (and should, of course) use public imports for backward 
> compatibility regardless of what we name the new modules.

Well, perhaps `tuple` is a clear enough name, and it could stand 
on its own, but what about things like BlackHole? 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`).
* After the split, existing users won't have troubles (however 
small) finding the modules as they would remain grouped under 
their original `typecons` parent
* Nothing to deprecate -> no future breaking changes