René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design Meeting Notes, 2/16/2018","articleBody":"# Recursive Conditional Types\r\n\r\nhttps://github.com/Microsoft/TypeScript/pull/21316#issuecomment-359275993\r\n\r\n* @tycho01 already reiterated we have recursive conditional types with indexed access types on object types (https://github.com/Microsoft/TypeScript/pull/21613#issuecomment-365774702)\r\n    * Well damn it, if you can already do it with object types, why make it ugly to do with regular conditional types?\r\n* Conditional types contain 4 types\r\n    * The checked type, the extends type, the true type, and the false type\r\n    * When the condition is *definitely* true or false, we do an immediate instantiation (/evaluation) of the respective branch\r\n    * Those branches are already sort of deferral points, much like the object member types.\r\n    * If an conditional type is instantiated over 100 times, we consider that to be too deep.\r\n        * At that point, we try to find the respective alias type that contains that conditional type.\r\n* *\\[\\[Demonstration of Peano-style arithmetic with multiplication]]*\r\n* Challenges\r\n    1. The \"we've instantiated too deeply\" error is issued on the declaration instead of the usage, which is not totally obvious.\r\n    2. The act of checking whether a type satisfies a constraint in a conditional type (e.g. seeing if `A` is assignable to `B` in `A extends B`) requires evaluating `A`.\r\n        * That means if `A` is a conditional type, either branch needs to be evaluated immediately to see if it satisfies `B`. That means you can end up exhausting your instantiation stack.\r\n* Question: Why not defer the type when comparing a conditional to the constraint type.\r\n    * doesn't make sense, you need to check *now*\r\n        * you could imagine that our compiler architecture was more deferred, but that would make it much harder to reason about.\r\n* Question: *or*, when you hit the limit, stop evaluating once you hit the limit and defer the evaluation?\r\n* Also, this instantiation stack limit is quite annoying: you can get errors on unrelated type aliases.\r\n    * What if your stack is tied per type instantiation?\r\n    * Or rather than per type, you use the global stack but check specific types in that stack.\r\n* Conclusion: give users an error in these situations, try to improve the message.\r\n\r\n# Ignore specific errors with `@ts-ignore` comments\r\n\r\nIssue: #19139\r\nPR: #21602\r\n\r\n* Given the error code, what are you actually suppressing?\r\n    * Seems entirely unclear.\r\n    * Error codes don't tell you what you're doing\r\n        * Short-names are better than numbers.\r\n* So short names?\r\n    * But this gives a bad UX; way more on the screen than you wanted.\r\n    * Also, people are *probably* relying on the error codes even though they shouldn't be!!\r\n    * What if we gave short codes in `--pretty`?\r\n* Could give quick info for the error code.\r\n    * Great but how does that help you on a code review on GitHub?\r\n        * Why, do you inherently distrust the code you're reviewing?\r\n            * Sometimes yes?\r\n* A lot of these are to suppress lint rules.\r\n    * Maybe the solution is just to get out of the linting business. :)\r\n* What if these comments caused errors when no error's present on the next line?\r\n    * We might feel better about that.\r\n        * Half jokingly: Can you suppress *those* errors?\r\n            * Now the idea has become a half-joke.\r\n* Conclusion: no conclusion *yet*.\r\n* Post-design meeting realization: original motivation was mass suppression for working code.\r\n    * Seems more reasonable with that in mind.","author":{"url":"https://github.com/DanielRosenwasser","@type":"Person","name":"DanielRosenwasser"},"datePublished":"2018-02-17T07:43:56.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":9},"url":"https://github.com/22011/TypeScript/issues/22011"}