Porting std.typecons to Phobos 3

[Jonathan M Davis]

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