Typescript: Design Meeting notes, 10/19/2018

[RyanCavanaugh]

• #13730 Path mapping with leading slashes
  
  
  
  • PR now available (#27980)
  
  
  • "This person used path mapping to set up their imports, which was their first mistake..."
  
  
  • Not crazy when you're hosting on a web server
  
  
  • We see this as the drive root, which is obviously madness
  
  
  • It looks like an absolute path but it's not
  
  
  • Is there any reason to not do this? We don't even need a flag
  
  
  • Not really a breaking change since you'd have to have an "incorrect" extant path mapping
  
  
  • Three kinds of path: relative, non-relative, absolute (relative and non-relative are not exact opposites)
  
  
  • What about ./ ?
  
  
  • Unclear what this means
  
  
  • No path mapping for these
  
  
  • What about importing from C:/foo or http://example.com/bar?
  
  
  • Technically absolute?
  
  
  • Is this legal to path map now?
  
  
  • //computername/module ?
  
  
  • Yes for all "rooted" paths
  
  
  • Should we make relative paths in path mappings an error?
  
  
  • Technically a breaking change
  
  
  • Last time we tried to be helpful we broke some people
  
  
  • Yes (Ryan to file separate issue)
  
  
  • :+1:
  
  
• #27050 Type parameters incorrectly assumed to be truthy
  
  
  
  • Buckle up.
  
  
  • Requires the "type facts" work Wesley prototyped
  
  
  • The correct return type of this function is something like Falsy<T> | number
  
  
  • Where Falsy<T> is a conditional type that produces a subset of "" | false | 0 | null | undefined
  
  
  • Then all higher-order narrowings are written in terms of these primitives
  
  
  • Consider if (!x) { x; /*1*/ } else { x /*2*/ } /*3*/x; for some x: T
  
  
  • At 1, x should have type Truthy<T>, at 2 has type Falsy<T>
  
  
  • At 3, x would have type Truthy<T> | Falsy<T> due to how control flow analysis works
  
  
  • We need x to go back to T again at this point or the type is effectively unusable
  
  
  • What is the merge strategy?
    
    
    
    
    
    • For some type T | U where T is W extends X ? Z1 : never and U is W extends X ? never : Z2, for the same X, T | U becomes Z1 | Z2
    
    
    
  
  
  • Now consider
    
    ts if (!x) { if (typeof x === "string" { x; // Stringy<Truthy<T>> } } else { x; } x; // Stringy<Truthy<T>> | NotStringy<Truthy<T>> | Falsy<T>
  
  
  • We would need rules to define commutativity and distributivity of conditional types
  
  
  • No obvious solution here
  
  
  • Possibly-useful observation: Extract<keyof T, "a" | "b"> is the same as (keyof T) & ("a" | "b") due to union-intersection distributivity and never-reduction
  
  
  • Now you have new problems!
  
  
  • Problem 1: Only certain provably-empty intersections get reduced, e.g. primitive-primitive collisions
  
  
  • We can't reduce other things like { __tag: void } & string because people use it for tagging
  
  
  • Also a problem due to non-object anonymous types like { toString(): string } which matches primitives
  
  
  • Problem 2: We don't have a built-in Exclude operator (subtraction types) for representing e.g.string - "a"
  
  
  • Should Extract / filtering operations be new primitives?
  
  
  • Does this actually solve anything?
  
  
  • No
  
  
  • ... maybe a new operator for "strict" intersection that more aggressively culls impossible intersections
  
  
  • The correctness upside here comes with a downside of type display madness
  
  
• #27507 Difference in CLI and server typechecking behavior
  
  
  
  • The spooky ghost of "best common subtype"'s "first supertype of all other types" behavior returns
  
  
  • Could it be written with one fewer type parameter?
  
  
  • What should happen when inference produces a disjoint set of candidates?
  
  
  • Do something else?
  
  
  • We could sort inferences by type IDs, which would at least make this more likely to be stable
  
  
  • The problem is that we have to produce something when there are multiple candidates, and want that thing to produce errors (usually), but there's no good type to produce here that behaves correctly in all variance directions
  
  
  • Need some type that is not assignable in any direction
  
  
  • ...
  
  

[sledorze]

I'm wondering if we're in a state where workarounds unsoundness and corner cases make things actually unintelligible for the - even experienced - end user?
That may not be the case and we may find a sweet spot but I'm questioning

[NN---]

"10/19/2019" :)