Porting std.typecons to Phobos 3

Adam Wilson flyboynw at gmail.com
Sun Nov 17 10:51:27 UTC 2024


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

Yea ... miscellaneous is never happening on my watch. That is 
pure ugly. :D

It wasn't something I thought of, but flattening out the modules 
a bit could be on the table.

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

I'm with JMD on the length of Option vs. Optional, and that's 
what the majority of other langs are going 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

One of the cool things about Phobos 3 is that backwards 
compatibility is not a primary goal although there will be *some* 
work to make of the transition easier. So if we think it would be 
prudent to re-open the design of something based on prior 
experience that is well within our scope. We do have to be 
mindful of time as there are a ton of modules/types to get 
through and very limited labor pool but beyond that we're here to 
build the best version of Phobos we can. If that means 
redesigning then that's what we do. JMD has already done a ton of 
redesign work on Traits.

As far as `Tuple` is concerned, Timon is working on building them 
into the language so that we don't need to worry about it. 
Apparently the implementation is done, he just needs to do the PR 
and DIP for it. We've been discussing on Discord whether or not 
to port the Phobos tuples at all.


More information about the Digitalmars-d mailing list