Skip to content

Design Meeting Notes, 12/20/2019 #35807

Closed
@DanielRosenwasser

Description

@DanielRosenwasser

A Stricter Subtype Relationship

  • Issue: Destructuring of optional fn + default function value gets signature from the value #35414

  • PR: Increase selectivity of subtype relationship for signatures #35659

  • We have this thing where we perform union subtype reduction - reducing constituents of unions when a union contains a supertype.

  • But we sort unions by a type IDs, but that's not a "stable" ordering.

    • Our current subtype relationship contains "ties" though - several types can be subtypes of each other.
    • First type ID wins, so if you reorder declarations/instantiations in your program, the behavior changes! That's undesirable.
  • The solution is to avoid places where types can "tie" in which types are supertypes.

  • It's strictly a good thing in subtype reduction, but it can have effects elsewhere.

    • One effect that's measured is that two constituents might be preserved in a reduced union (something we're willing to take).
    • Additionally, because of our union merging, we might have different effects on which signatures are present.
    • Also seeing differences in overload resolution because overload resolution does a subtype pass.
      • Historical reasons for saying any is not the best type to choose from.
  • These changes introduce a lot of potential breaks elsewhere, so we introduced a separate relationship to the compiler.

    • Ideally we'd use this new subtype relationship everywhere, but we don't want to impact too much.
  • Example breaks seem "good" but hard to deal with.

  • Could we imagine a strict mode that uses the strict subtype relationship?

    • Maybe! It's worth thinking about.
  • As a compiler writer, what relationship do I use?

    • [[rules that went by too fast, but you can consult with the team]]
  • Conclusion

    • Turn it on just for subtype reduction.
    • Try it out everywhere, see what breaks, see if it can fit under a strict mode - i.e. --strictSubtypes but with a better name.

Assume Changes Only Affect Dependencies

Type-Only Imports/Exports

#35200

  • Scenarios
    • Re-export a type in isolatedModules
    • Stop eliding imports when I do DI
  • Behavior
    • Changed default emit behavior to preserve imports
    • Flag to opt in to the old behavior
  • Effect
    • Can increase bundle sizes 👎
    • Hard to determine where to fix 👎
    • Runtime behavior might break, or you might not notice the change at all 👎
  • Proposals to mitigate issues
    • Proposal 1
      • Add error on regular imports used only as types.
      • Disable error via a flag.
    • Proposal 2
      • Keep today's emit behavior.
      • Opt into preserved imports via a flag
      • Optionally enable this in tsc --init
      • Optionally add a flag to force type-only imports for identifiers used only as types
    • Proposal 3
      • Transition plan
  • 3 years from now where do we want to be?
    • Can we remove things from the import list under isolatedModules currently?
      • Yes
    • Anecdotal from Wesley: when I transitioned our unit tests into modules, there were a lot of issues because our unittests were only being included via type-imports.
      • Experience is that elision has undesirable behavior
    • This is a very big breaking change even if you phase it over several releases.
      • People are in an unknown state of what they want - only make noise (i.e. give an error) when the intent isn't clear.
  • Can this be a strict mode flag?
    • Strict flags have never affected emit.
  • Could this be mitigated with a tristate flag?
    • Well then what's the default?
  • Conclusion:
    • The safer proposal 2
      • Leaves our options open
    • Implement option as a tristate
    • preserve be default in tsc --init
    • Send PRs to 3rd party tools
      • Turn it on in scaffolding tools
      • Babel
        • Need to signal to the team, maybe need a flag (@hzoo).

Use Getters for Live Bindings

#33587

  • Turns out even we were giving people "wrong" exports because of this.
  • Let's do it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions