On Sat, Sep 7, 2024, at 01:34, Larry Garfield wrote:
> On Fri, Sep 6, 2024, at 6:27 PM, Rob Landers wrote:
>
> >> I suspect there's also other edge case bits to worry about, particularly if
> >> trying to combine a complex alias with a complex type, which could lead to violating the DNF rule.
> >> For example:
> >
> > Oh, DNF is the bane of my existence with this RFC—I don't want to mess
> > this up. I'll see you at the end of the example, though.
> >
> >>
> >> typealias Foo: (Bar&Baz)|Beep;
> >>
> >> use (Bar&Baz)|Beep as Foo;
> >>
> >> function narf(Foo&Stringable $s) {}
> >>
> >> With the compile time approach, that would expand to
> >> (Bar&Baz)|Beep&Stringable, which is not a valid type def.
> >
> > I can see how you arrived at this, but I think you may have missed a
> > step, since the entirety of Foo will be &'d with Stringable.
> >
> > Foo = (Bar & Baz) | Beep
> >
> > want: (Foo) & Stringable
> >
> > expand Foo: ((Bar & Baz) | Beep) & Stringable
> >
> > Which can be reduced to the following in proper DNF (at least, it
> > compiles—https://3v4l.org/0bMlP):
> >
> > (Beep & Stringable) | (Bar & Baz & Stringable)
> >
> > It's probably a good idea to update the RFC explaining how expansion works.
>
> Woof. We're not "fixingup" anyone's DNF elsewhere. I cannot speak for
> everyone, but I'd be perfectly fine not doing any magic fixing for now, and then debating
> separately if we should do it more generally. Just doing it for aliases doesn't seem like the
> best plan.
>
> --Larry Garfield
>
Oh, we're definitely not "fixingup" the expression to DNF... more like spending some
time in the RFC showing how the expansion is the same execution as with a DNF expression to prove
that it is a valid type expression.
— Rob