Skip to content

Design Meeting Notes, 11/19/2021 #46878

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

Closed
DanielRosenwasser opened this issue Nov 20, 2021 · 0 comments
Closed

Design Meeting Notes, 11/19/2021 #46878

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

Comments

@DanielRosenwasser
Copy link
Member

Strict Class Initialization with Computed Properties

#45974

  • PR closes a bunch of bugs.
  • In strictClassInitialization, we check for "regular" properties, but not properties declared as comuted properties.
  • Why is this different from other narrowings?
    • Well we have to specifically create a "reference" to understand how a computed
  • Still adding to control flow graph.
  • Need some eyes before we merge.

Issues with Parameters and ReturnType

#46855

  • MethodKeys extends Methods<T> -> T with only its methods

    • T[Method] took us too long to expand, and said "maybe!" and let it pass through.
    • Now we can tell that this is really an invalid option.
  • We "narrow" Methods based on some criteria, but then try to index back into T with it, and don't have any way to surface that criteria.

  • Can use... a type helper called Cast 😬

    type Cast<T, U> = T extends U ? T : T & U;
  • How often does this come up?

    • Mongoose types got hit, their conclusion was the type was wrong.
  • Would be nice if we had a first-class primitive to handle this.

    • Higher order encoding?
    • Maybe just a new primitive.
  • Aside: all of this is very hard to reason about!

  • The Maybe behavior seems like the wrong thing.

    • Most upsetting thing about this is not the change in behavior, it's that we didn't do this before and people accidentally took a dependency.

satisfies Operator (Contextually Typed-by and Assignable-to Operator)

#7481

  • Need to write down the 2-3 use-cases.

  • Details like freshness, excess property checking, etc.

  • Until then, hold off on the PR, but we want to use it to play with different behavior.

  • Had a lot of syntax discussions, but the semantics are going to drive the syntax.

  • Maybe use a different keyword to ensure we're not tying any preconceived ideas?

  • What if you could write const anywhere in an as and it inferred the const-y version of the expression type? Then you could write

    type Validate<C, T extends C> = T;
    
    { x: 0 } as Validate<Point2D, const>;
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Nov 20, 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