Design Meeting Notes, 6/9/2017 · Issue #16415 · microsoft/TypeScript (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

Stricter generic signature checks

• Already did some work in Infer from generic function return types #16072 to perfom type argument inference using the return type of a signature as a target.
• In Contextual generic function types #16305 we added support for signatures to gain type parameters from their contextual types.
  • This behavior is more appropriate because it respects the constraints and the universality of each usage of type parameters.
• To follow up with this, we're introducing stricter generic signature checks (Stricter generic signature checks #16368).
  • Previously, when relating type parameters, we would erase them with the type any.
  • This was fairly unsafe.
  • Previously the following would work, but with Stricter generic signature checks #16368, the following is an error.
    type A = <T, U>(x: T, y: U) => [T, U];
    type B = (x: S, y: S) => [S, S];
    function f(a: A, b: B) {
    a = b; // Error
    b = a; // Ok
    }
  • This is kind of a form of unification between the two parameters.
    * We infer using the type parameters of the target, as if we were calling the source with the target's parameters.
    * In other words, in a = b above, it simulates calling b with a's parameters.
  • The caveat is that this logic is only applied to single-signature types.
    * Any times you have overloads, it becomes extremely difficult to perform these checks.
• So the question is: do we put this behind a flag?
  • Most errors are good, but it's hard to figure out what to do for some advanced scenarios.
  • Get it into master and see what we can work with.

Private Slots

Proposal: https://github.com/tc39/proposal-private-fields/ (Permalink)

Repo: https://tc39.github.io/proposal-private-fields/

• How does this work with existing modifiers?
  • See Compatibility with ECMAScript Private Fields proposal #16324 (comment)
• Can we offer a true downlevel translation?
  • To ES5?
    * No.
    * Need weakmaps
  • Yes above ES6.
• Could give a mangled name in ES5/ES3.
  • Has potential problems.
    * Proxies, enumeration, etc.
    * Proxies and the like don't exist in ES5.
    * Best effort might be fine.
• What about using Symbols in ES6?
  • Symbols aren't truly private - can be used by proxies, can be iterated over, etc.
• Weakmaps make it truly private.
  • Are they performant?
    * Concerns over the type of GC pressure it may cause.
    * Edge is good at this!
    * Implementation is that every object has a list of weakmaps so that the lookup is inverted.
    * Others not as much at this point in time.
    * But will eventually improve!
  • But it's all opt-in.
  • Is it possible that all users really want is design-time private?
    * There are definitely people who've wanted private state.
• P.S. everyone hates the syntax. we're not big on the syntax
• Completely unrelated
  • The proposal breaks JScript 5.8 in IE 8.
    * ¯\_(ツ)_/¯
• We'll all need to go over the FAQ more closely on the private state proposal repo.
  • https://github.com/tc39/proposal-private-fields/blob/master/FAQ.md