René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design Meeting Notes, 1/18/2023","articleBody":"# `newLine` and `forceConsistentFileNames` Defaults\r\n\r\n#51909\r\n\r\n* `newLine` to `lf`?\r\n    * Didn't get to discuss it thoroughly.\r\n* Change default of `forceConsistentFileNames` to `true`?\r\n    * Catch issues between Windows/Mac/Linux ahead of pushing out to CI.\r\n    * We think it's good to turn on.\r\n* We all feel okay about the fact that it doesn't \"do what people think\", right?\r\n    * \"What?\"\r\n    * It doesn't check whether the paths match what's on disk, it just checks whether the paths are consistent across the project.\r\n* Deprecate it?\r\n    * Prefer not to.\r\n* Conclusion\r\n    * `--newLine lf` by default.\r\n    * `--forceConsistentFileNames true` by default.\r\n\r\n# `catch` Clause Variables\r\n\r\n#52240\r\n\r\n```ts\r\n// @useUnknownInCatchVariables: false\r\n\r\ntry {} catch ({ e }) {}\r\n//              ^?\r\n\r\ntry {} catch ({ e }: any) {}\r\n//              ^?\r\n\r\ntry {} catch ({ e }: unknown) {}\r\n//              ^?\r\n\r\n\r\ntry {} catch ({ x: { e } }) {}\r\n//                   ^?\r\n\r\ntry {} catch ({ x: { e } }: any) {}\r\n//                   ^?\r\n\r\ntry {} catch ({ x: { e } }: unknown) {}\r\n//                   ^?\r\n```\r\n\r\n* Toggle `useUnknownInCatchVariables` between `true` and `false`.\r\n* When `true`, the annotations are ignored, and destructured declarations are permitted and `unknown`.\r\n* #52240 fix this.\r\n* Breaking change, but only found buggy code under `useUnknownInCatchVariables`.\r\n    * We think this is good for 5.0.\r\n* Also: #52280 allows arbitrary type annotations on catch variables - addresses #20024.\r\n    * But we're not doing that, right?\r\n    * No, blatantly unsafe.\r\n    * Well then we should tell people that we're not doing it?\r\n        * Context matters - we think pattern matching progressing in TC39 is going to enable a safe version of this pattern.\r\n        * We want to defer to that.\r\n* Conclusion\r\n    * We're not doing #52280.\r\n    * We're doing #52240.\r\n\r\n# Comparison Operators\r\n\r\nhttps://github.com/microsoft/TypeScript/issues/52036\r\nhttps://github.com/microsoft/TypeScript/pull/52048\r\n\r\n* Some obvious but questionable things that popped up.\r\n    * `Number \u003c number` now disallowed\r\n    * `string | number \u003c number` now disallowed\r\n    * `unknown \u003c number` now disallowed\r\n* Some stuff that fails due to control flow limitations across functions.\r\n* What about objects that coerce to `number` (e.g. `Date`)?\r\n    * Why don't we look at `valueOf`?\r\n        * Or `[Symbol.toPrimitive]`?\r\n        * Here we go...\r\n* Conclusion: Feels like this PR is a good start. Want to bring this in for 5.0.\r\n    * Watch for 5.0 Beta feedback.\r\n\r\n# `JSON.stringify`\r\n\r\n#51897\r\n#52250\r\n\r\n* This thing broke some code.\r\n* Technically `stringify` can return `undefined`.\r\n    * But technically also wrong because a `Function` can have a `toJSON` method.\r\n* There's a world where we could possibly keep this as-is if we reordered the signatures so that `never` works.\r\n    * Overload resolution goes through a subtype pass.\r\n* But why are we adding this overload? Who ends up in a situation like this?\r\n    * Doesn't even catch mistakes like `(() =\u003e string) | string` today.\r\n    * Only contrived cases are caught.\r\n* The idea that everyone has to suffer for `stringify` because of these contrived-but-uncommon cases feels unreasonable.\r\n* Could ship an open-ended union?\r\n* Could also just tell people to interface-merge.\r\n* Conclusion:\r\n    * Revert this, tell people to interface-merge on `JSON` with something that returns `undefined`.\r\n\r\n# Picking Between Types from Type Predicates and Original Types\r\n\r\n#50916\r\n\r\n* Made a change a while back to pick the types from type predicates/type assertions.\r\n* Similar behavior with `instanceof` too.\r\n* Means that the original type does not survive at joining points of CFA.\r\n* Idea\r\n    * In the true branch, we will still prefer the type predicate type.\r\n    * In the false branch, we will now *preserve* the original type so that they join back at a CFA merge node.\r\n* So what do we now do about mutual subtypes?\r\n    * For example, `unknown` and `any` are mutual subtypes.\r\n    * Today we choose the type with the lowest ID.\r\n    * Pretty unfortunate - these have measurable effects.\r\n    * So we are making `any` a *strict supertype* of `unknown`.\r\n        * Behavior directly in unions is the same.\r\n        * Where else does this appear?\r\n            * When the type IDs are not compared directly.\r\n            * So for e.g. `Array\u003cany\u003e` vs. `Array\u003cunknown\u003e` - but `Array` is not special.\r\n\r\n              ```ts\r\n              type Box\u003cT\u003e = { readonly value: T };\r\n\r\n              declare let anyBox: Box\u003cany\u003e;\r\n              declare let unknownBox: Box\u003cunknown\u003e;\r\n\r\n              let boxes1 = [anyBox, unknownBox];\r\n              //  ^?\r\n              let boxes2 = [unknownBox, anyBox];\r\n              //  ^?\r\n              ```\r\n            * Now you always end up with `Box\u003cany\u003e[]`.\r\n    * Similar constraints with `{}` and any non-empty object type.\r\n* What other effects does this have?\r\n    * The type of an assignment expression is always the right side:\r\n\r\n      ```ts\r\n      function f(obj: { a?: string }) {\r\n          (obj = {}).a; // allowed?\r\n      }\r\n      ```\r\n\r\n    * Hmm...\r\n\r\n      ```ts\r\n      function f(a: { x?: number }, b: { x?: string}) {\r\n          a = b = {}; // allowed?\r\n          // Equivalent to `a = (b = {})` which naively looks like `b = {}; a = {}` from a type perspective.\r\n\r\n          a.x = 42;\r\n\r\n          b.x?.toUpperCase();\r\n      }\r\n      ```\r\n        * Fresh `{}` object type has \"inverted\" subtype behavior.\r\n            * It is, but on the assignment we widen.\r\n            * Do we have to widen? Could choose not to.\r\n            * Feels like for the `b = {}`, we have to propagate out some information, or further narrow based on the left side(?)\r\n    * `(...args: any[]) =\u003e any` should be a super-type of all functions?\r\n        * But what about `(...args: never[]) =\u003e unknown`?\r\n            * Not specially understood today by TS internals.\r\n","author":{"url":"https://github.com/DanielRosenwasser","@type":"Person","name":"DanielRosenwasser"},"datePublished":"2023-01-18T23:19:24.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":12},"url":"https://github.com/52296/TypeScript/issues/52296"}