Better assignability errors to never-producing vacuous intersections#37618
Uh oh!
There was an error while loading. Please reload this page.
Conversation
…ets reduced to 'never'.
DanielRosenwasserforce-pushed the betterNeverErrors branch from e30996e to 9e73730CompareDanielRosenwasserforce-pushed the betterNeverErrors branch from 9e73730 to 13269b3CompareDanielRosenwasser changed the title 
| ab.kind; // Error | ||
| ~~~~ | ||
| !!! error TS2339: Property 'kind' does not exist on type 'never'. | ||
| !!! error TS2339: The type 'never' was reduced from the intersection 'A & B'. Each type of that intersection has properties that conflict, so values of that type can never exist. |
There was a problem hiding this comment.
You should probably search for and report the properties that conflict and their respective types, no? So the error is somewhat more actionable?
There was a problem hiding this comment.
Definitely seems doable, but only if the approach in this PR seems reasonable.
There was a problem hiding this comment.
Seems OK. We could probably consider leaving behind more "breadcrumbs" like this in the future to explain how a specific type came about; but it's always about striking that balance between useful explaianation and terseness.
sandersn left a comment
sandersn left a comment There was a problem hiding this comment.
Error seems good, and implementation seems OK except for the flags problem.
| "category": "Error", | ||
| "code": 18030 | ||
| }, | ||
| "The type 'never' was reduced from the intersection '{0}'. Each type of that intersection has properties that conflict, so values of that type can never exist.":{ |
There was a problem hiding this comment.
why 'each' here? Wouldn't 'some' be correct?
If that's true, I'd just say "Types in that intersection ..."
DanielRosenwasser commented Apr 3, 2020
#37618 provides the better error message. |
This was a naive first pass at something that I realized would be nice as I wrote up the breaking change section.
I couldn't do a fix everywhere because it became pretty impractical - for example, by the time we do the checks in some places, assignability, I guess we're given
neverinstead of the original intersection.Things I'd like some guidance on:
1 << 29onNodeBuilderFlags. I've forgotten if that means I get a prize or a scolding for hitting the max unboxed value on a flag. (thanks @yuit)