Porting std.typecons to Phobos 3

[Paul Backus]

On Saturday, 9 November 2024 at 04:34:20 UTC, Adam Wilson wrote:
> The first thing I'd like to consider is renaming to 
> `phobos.sys.types`. It is difficult to name `std.typecons` 
> because it is a grab-bag of type-related tools. [...]
>
> Second, JMD proposed that we re-organize this module into a 
> package due to it's grab-bag nature. [...]
> My proposal is to break this module up by the categories in the 
> document with the exception of `Nullable` which will get it's 
> own file module due to it's size.

It's difficult to name because the most accurate name for 
`std.typecons` is `std.miscellaneous`. :)

Ideally, Phobos 3 should not have a "miscellaneous" package at 
all. Instead, each individual part of `std.typecons` should get 
its own module, and we should decide on a case-by-case basis how 
(or whether) to fit them into the overall structure of Phobos 3.

> Speaking of `Nullable`, after a rather embarrassing situation 
> with a Phobos 2 PR on `Nullable` JMD and I agreed that it 
> should be renamed as it does not actually behave like a 
> nullable but instead behaves as an "Optional" type. We 
> considered `Optional`, `Maybe`, and settled on `Option` as that 
> appears to the more popular naming choice in other languages 
> and is almost as short as `Maybe`. If you disagree I'd love to 
> hear your case.

Personally, `Option` would be my last choice, because the word 
"option" can also refer to things like command-line flags and 
configuration values. The Dub package [`darg`][1], for example, 
has an `Option` UDA that would conflict with this usage.

Between `Optional` and `Maybe`, I'm indifferent.

[1]:https://code.dlang.org/packages/darg

> The last question is how we want to deal with existing bugs in 
> V2 as we port the code to V3. My view is that it would be 
> prudent to fix any bugs that have been opened as we go in both 
> V2 and V3. Currently I've found a number of bugs against 
> `Nullable` and `Tuple`, the two types I'd like to start with.

Do we want to just port the existing versions, or are breaking 
API changes and reimplementation on the table? For example, 
there's been talk about removing the range interface from 
`Nullable`, and Andrei's comments in [issue 18462][2] suggests 
that splitting `Tuple` into separate implementations with and 
without field names might be desirable.

To me this seems like a good opportunity to give a critical eye 
to the current designs, and potentially let go of some of Phobos 
2's baggage.

[2]: https://issues.dlang.org/show_bug.cgi?id=18426