Porting std.typecons to Phobos 3 (page 3)

On Sunday, 17 November 2024 at 12:51:44 UTC, Paul Backus wrote:

Is there any place where interested parties can check on the current state of Phobos 3 development, and find out which modules/types are in-progress vs. up for grabs? If not, it might be a good idea to create one--maybe a Github projects page, like the one in this recent announcement.

Not at the moment. I've asked Razvan to create a project on the DLF Projects page that I can manage (and get all the state info out of my head), but I don't have the access myself.

Built-in tuples for Phobos 3 would be awesome! If they support named fields, then there's definitely no reason to keep Phobos Tuple around IMO. If not, there might be room in Phobos 3 for a NamedTuple type (a la Python).

I don't know if Timon's tuple's have names, but if they don't we'll have to do a NamedTuple.

December 23

Re: Porting std.typecons to Phobos 3

Posted by Atila Neves
in reply to Paul Backus

Permalink

Atila Neves

Posted in reply to Paul Backus

Permalink

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, for example, has an Option UDA that would conflict with this usage.

Between Optional and Maybe, I'm indifferent.

Also this.

> >

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.

On Saturday, 16 November 2024 at 23:17:33 UTC, Paul Backus wrote: > 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. I’d also have gone with `Optional` instead. As a nonnative speaker I find `Option` rather confusing. And my dictionary couldn’t really help me make sense of it either. Is this actually an idiomatic usage of that word? Or is it a homemade abbreviation of “optional”? Technically, `Option` appears to be more like a two-“Options” type – to me at least. I don’t think saving two characters is worth it. Text editors with dictionary completion (or better) should be able to pick this up in no time – especially if it’s “this is going [to be] routinely used”. Given that it will reside in a module sharing its name (i.e. it’s identifier is already there in the file once it’s been imported), I’d assume this should be a no-brainer in practice.

Forums