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

[Paul Backus]

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.