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