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, 2/26/2021 #42992

Closed
DanielRosenwasser opened this issue Feb 26, 2021 · 0 comments
Closed

Design Meeting Notes, 2/26/2021 #42992

DanielRosenwasser opened this issue Feb 26, 2021 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Remove Enum/Number Comparability

#42472

  • We have a bizarre rule that all enum values with all numeric or numeric literal values.
  • We have this rule because bitflag enums sometimes end up looking like union enums, so we to not be too restrictive.
  • So number is comparable with all numeric enums in some direction.
  • We can't get rid of the assignability rule.
  • But we can get rid of the comparable relationship.
  • If we get rid of the rule, then we end up saying 0 will never be comparable with an enum like enum E { A = 1, B = 2}.
  • In one break, coders should've neen expecting -1 | SomeEnum.
  • In another break, the users really wanted the enum to be open-ended, so you can approximate that by opting out of union enums.
  • Is E.A still comparable with its literal value?
    • Yes.
    • enum E { A = 1 }; E.A === 1 // works
  • Only thing that seems spooky is prefixing one of the literal values with a +.
  • Does this affect bitflag enums?
    • Depends on how you declare your bitflag enums.

    • If you compute with <<s, then you'll continue getting a non-union numeric enum.

      enum E {
          A = 1 << 0,
          B = 1 << 1,
          C = 1 << 2,
      }
    • But if you decide to write out each of your enum values...yes, you will be affected.

      enum E {
          A = 0b00000001,
          B = 0b00000010,
          C = 0b00000100,
      }
    • This is super subtle. And the fix is not obvious.

      enum E {
          A = +0b00000001,
          B = +0b00000010,
          C = +0b00000100,
      }
  • Let's review the original use-case.
    • Well, we keep narrowing down to negative.
  • Alternative solution: if you have unit types, maybe you can do something more specific here?

Optimized Checking for Discriminated Unions

#42556

  • Original idea:
    • 500 action types with unique discriminants
    • Structurally compatible, but not-the-same object literals.
    • 2 seconds to check that array + contextual types.
  • Compilers-with-Unions: 30% faster! Monaco is faster too!
  • Using "constituent maps" when
    • checking assignability to a large discriminated union target.
    • reducing large discriminated union types that appear as contextual types.
    • control-flow analysing and narrowing large discriminated unions
  • Caches results of subtype reduction when constructing union types.
    • Every time you try to construct a union type from a set of types, you have to do subtype reduction. So we're now caching the resulting subtype from the input types.
  • Performs deduplication of structually equivalent object/array literals.
    • Create some sort of string representation for every literal, then deduplicate based on that.
    • What if you end up not being able to?
      • No worse-off, this is just a way to optimize ahead of time.
  • Uses discriminant properties to disqualify types from subtype checks in subtype reduction.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Feb 26, 2021
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

1 participant