Repository navigation
"Special" intersections (such as string & {}) are no longer order-independent since 4.8Β #53043
Description
Activity
Was looking for the dupe for like 10 minutes because I knew this had come up very recently. Felt stupid when I finally realized it was your own PR.
Reacted by Mateusz BurzyΕski, Toni Villena, Ryan Cavanaugh and Evgeniy IstominIβm pretty sure I recall Anders saying this was intentional, though #49119 doesnβt say outright.
Ye, at the end of the day - I don't think this is a big deal. However, I actually lost like 15 minutes of my life, scratching my head why this thing doesn't work - only to realize later that I've written those two in reverse order. A general rule of thumb is that the order of the intersection shouldn't matter, right?
A general rule of thumb is that the order of the intersection shouldn't matter, right?
This is what I thought, and I spent a bunch of time trying to make them sorted, but it does matter for overload ordering and that can affect basically anything. I can't think of any reason for it to matter for explicitly just
string & {}though.That being said, it seems cheap to just compare them both ways.
Anders Hejlsberg (@ahejlsberg) any specific thoughts?
Very close to making a specific "Not sure if bug, but Andarist can certainly send a PR if interested" label...
Reacted by Mateusz BurzyΕski, Emanuel Hoogeveen and ritschwummToo late: #52782
I don't feel strongly about fixing this, but the fix certainly looks fine to me.
That said, we should of course run the full battery of tests on the fix to make sure it doesn't break anything.
Bug Report
π Search Terms
string autocomplete catch all intersection special
π Version & Regression Information
β― Playground Link
Playground link with relevant code
π» Code
π Actual behavior
Since 4.8 the second function doesn't provide completions despite using an intersection with the same members as the first one.
π Expected behavior
I would expect both to behave the same, regardless of the order of the intersection members.