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