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

On Sunday, 17 November 2024 at 03:13:20 UTC, Jonathan M Davis wrote:
> e.g. in the case of Nullable [...] adding the ability to cast to bool in addition to using hasValue (or whatever we call the replacement for isNull)

https://github.com/dlang/phobos/pull/9039

> 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 don't think this is a great idea. Option!T has value semantics (w.r.t. the T value), but T* has reference semantics, so generic code that tries to work with both will likely fall into the same pitfalls that code using input ranges currently does.

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

Mathis Beer/FeepingCreature did a bunch of work on this, including a DConf talk [1]. Might be worth getting in touch with him.

[1] https://www.youtube.com/watch?v=eGX_fxlig8I

On Sunday, November 17, 2024 5:08:14 AM MST Paul Backus via Digitalmars-d wrote:
> On Sunday, 17 November 2024 at 03:13:20 UTC, Jonathan M Davis
>
> wrote:
> > e.g. in the case of Nullable [...] adding the ability to cast to bool in addition to using hasValue (or whatever we call the replacement for isNull)
>
> https://github.com/dlang/phobos/pull/9039
>
> > 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 don't think this is a great idea. Option!T has value semantics (w.r.t. the T value), but T* has reference semantics, so generic code that tries to work with both will likely fall into the same pitfalls that code using input ranges currently does.

Hmm. You may be right about that. There are definitely cases where you want that kind of behavior, but it may be better to do that with a type specifically for that.

> > 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.
>
> Mathis Beer/FeepingCreature did a bunch of work on this, including a DConf talk [1]. Might be worth getting in touch with him.
>
> [1] https://www.youtube.com/watch?v=eGX_fxlig8I

Yeah. I actually had to fix some bugs introduced by some of his improvements to Phobos v2 for Rebindable-related stuff recently, since it has to play some fun games with the type system to work, and there was a corner case that was missed, which unfortunately, happens too often with some of this kind of stuff. So, I need to look at the improvements which have been made and figure out how to make it all more cohesive. In particular, I think that we need distinct types for specific use cases rather trying to make the same wrapper type work with everything (e.g. the use case of having a mutable reference to a const class is fundamentally different from trying to reuse memory on the stack for different const structs, and having a thread-local reference to a shared class reference needs to be its own thing). And unfortunately, move constructors are probably going to make the situation more complicated. So, I need to sit down and work through all of that, and I'm sure that Mathis will want to give feedback on it.

A key question in all of it is how best to handle ranges which hold their elements (or even just front) directly on the stack, since some of what Mathis has done has been geared towards being able to "rebind" immutable values so that ranges which hold their values on the stack can work with them, and I'm not sure if we want to have the ranges themselves worrying about that or whether we're going to be better to have the user wrap them instead. Trying to have ranges handle that case for us potentially means having ranges in general having to use wrapper types internally, which isn't great, but holding data on the stack tends to be an implementation detail of ranges, so I'm going to have to take the time to work through that and propose what makes the most sense. Mathis has already expressed interest in seeing how the new range stuff deals with all of that, since it directly affects how they use ranges where he works.

In any case, thanks for the reminder and the link.

- Jonathan M Davis