Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 9/4/2020 #40434

Closed
RyanCavanaugh opened this issue Sep 8, 2020 · 1 comment
Closed

Design Meeting Notes, 9/4/2020 #40434

RyanCavanaugh opened this issue Sep 8, 2020 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@RyanCavanaugh
Copy link
Member

  • Don't widen inferred return types when a contextual signature is available #40311 Don't widen inferred return types when a contextual signature is available
    • Long-standing issue Don't widen return types of function expressions #241
    • Problem today: When strictNullChecks is off, null and undefined are widened to any before generic inference occurs
      • Example: f<T>(a: () => T, b: () => T): T under f(() => null, () => 1)
      • Proposal: Widen them later
    • Problem today: Excess property checking doesn't occur on a return expression contextually typed by a concrete object type
      • Examples: Countless
      • By not widening, we retain freshness and can correctly detect excess properties
    • Never widening is not the right solution
      • You have to widen if you end up inferring a type for a binding, otherwise object literals stay "fresh" forever which is wrong outside of a transient context
        • e.g. const a = () => { x: 3, y: 4 }; const b: () => { x: number } = a should be legal, but wouldn't be if we kept the freshness around
      • Named function expressions can call themselves, which is problematic for functions with recursive returns
    • Solution: Only defer widening when a contextual signature type is present
    • Found a bug in our own codebase
    • Found real problems in DefinitelyTyped (either bad docs or copy/paste errors)
    • Found things that appear to be bugs in RWC
    • Limitations: Same problems when contextual types aren't present (e.g. overload positions)
    • Investigate impact on binding patterns
      • const { x = () => true }/*: OptionalAnnotation */ = { x: () => false };
    • What's going on in wideningTuples2.ts testcase?
      • Named function expressions observe their unwidened form when they reference themselves
      • Options:
        • Ignore
        • Don't not widen named function expressions
        • Rewire the lookup logic?
      • Is this a blocker?
      • What other manifestations of this might exist?
      • Resolve offline
    • Looks good to go for beta
    • Please review!
  • --noImplicitOverride #39669 pedantic override
    • override without a flag to enforce it is mostly useless
      • But can't be on under --strict because no one has the ability to write override yet
      • Catch-22
    • What is the ordering of keywords?
      • public abstract override foo()
      • public static override foo()
  • pedantic index signatures
    • PR is ready
    • Remaining complaints are pre-known limitations
    • Should investigate current perf penalty of narrowing on x[i] for const i
      • Last two attempts showed 5% perf hit
  • pedantic thesaurus party
    • pedantic
    • stringent
    • rigorous (or if Ryan is listening, vigorous 🙃)
    • conservative
    • (no word at all)
    • indexedAccess vs indexSignatures
    • OT: we should have --init-strict or something
    • Wes brings up that we have --noFoo flags already that aren't part of --strict
      • --noUncheckedIndexedAccess
      • --noUncheckedIndexedAccesses
      • --noUncheckedIndexes
      • --noUncheckedIndices
      • --noUncheckedIndexing
      • --noImplicitBounds
      • --noImplicitAccess
      • --noImplicitIndexAccess
      • --noUncheckedLookup
      • --checkArrayBounds
      • --noImplicitIndexing
      • --undefinedIndexSignatures
      • --noBoundsAssumptions
      • --skepticalIndexAccesses
      • --🤨
      • --letsRunAPoll
@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label Sep 8, 2020
@RyanCavanaugh
Copy link
Member Author

Poll up at #40435

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants