Porting std.typecons to Phobos 3

[Atila Neves]

On Saturday, 16 November 2024 at 23:17:33 UTC, Paul Backus wrote:
> 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.

This.

>> 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.

Also this.

> [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.

And also this.