Porting std.typecons to Phobos 3
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Sun Nov 17 03:13:20 UTC 2024
On Saturday, November 16, 2024 4:17:33 PM MST Paul Backus via Digitalmars-d
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.
Personally, I prefer Maybe, which several languages have, but Option and
Optional are more common IIRC. Either way, I'd much prefer to avoid
Optional, because it's needlessly long, and this is going routinely used
explicitly to wrap types, making having the name be longer particularly
annoying. Adam didn't seem to particularly like Maybe.
> 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
IMHO, we definitely should be looking at reworking these types as
appropriate, since we don't need to maintain backwards compatibility with
these. There is no reason to stick to the current API just because it's what
we have when we can do better. And there are some obvious changes that I
think we should be making - e.g. in the case of Nullable, getting rid of the
range API (or at minimum making it so that it has to be sliced explictly to
get a range), adding the ability to cast to bool in addition to using
hasValue (or whatever we call the replacement for isNull), and adding the
ability to dereference it (that way, it can be used in if conditions just
like a pointer, and templated code could work with either pointers or
Option/Maybe/Whatever ). I'd have to sit down and study the types more to
say much more than that off the top of my head though. And in general, I
think that we should lean towards not porting some of these types if we're
not sure that they're generally useful, particularly since what's there is a
bit of a hodgepodge.
Personally, it's on my todo list to sit down and look through how Rebindable
and friends need to be reworked, since that's kind of a mess, and some of it
is potentially going to affect how we deal with ranges.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list