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 for 4/15/2016 #8112

Closed
DanielRosenwasser opened this issue Apr 15, 2016 · 0 comments
Closed

Design Meeting Notes for 4/15/2016 #8112

DanielRosenwasser opened this issue Apr 15, 2016 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Control flow based type analysis (#8010)

let x: string | number | boolean;
x = "";             // 1

while (/*...*/) {
    x;              // 2
    x = foo(x);     // 3
    x;              // 4
}
x;                  // 5

function foo(x: string): number;
function foo(x: number): boolean;
function foo(x: boolean): string;
function foo() {
    // ...
}
  • How do you determine all the types of x?

    • We are certain that x can at least have type string.
  • Issues with loops.

    • The type in a loop can go through an "evolution" of types.
    • Have to iterate to a fixed point to get the "eventual" type of that variable.
    • The compiler is not written to fully accomodate this scenario.
    • Symbols are not equipped to have types that vary.
    • Can create a mechanism to allow a variable whose declared type can go through iterations.
    • Currently this means we do a lot more overload resolution
      • Adds quite a bit of work to large projects like Monaco.
      • Unclear how to handle some situations with editor scenarios.
    • We will need to try this all out with existing code.
  • Need to introduce the notion of "incomplete types".

    • Iterate until a type does not change and then "complete" the type.
  • What if you never hit a fixed point?

    • Recall, when we see an assignment, we reduce the declared type of x, we don't add!
  • Still issues with circularly dependent variables:

    let x: string | number | boolean;
    x = "";             // 1
    
    while (/*...*/) {
        x;              // 2
        let y = foo(x); // 3
        x = y;          // 4
        x;              // 5
    }
    x;                  // 6
    
    function foo(x: string): number;
    function foo(x: number): boolean;
    function foo(x: boolean): string;
    function foo() {
        // ...
    }

Some other issues

  • Allow comaprison to undefined and null even if they're not in the union of types you have.
    • We're disallowing defensive code even though you could be called from within JS.
    • Should allow it.

Functions with this types called with new (#8109)

interface FooType {
    x: number;
}

function Foo(this: FooType, x: number) {
    this.x = x;
}

let foo = new Foo(12);
  • Should Foo be new-able?
    • Foo might be a plugin or callback with an intended this binding.
    • Really a new syntax should clarify the intent.
    • Signatures like function new Foo(x: number): FooType;.
    • 👍 for new signature syntax.
    • Needs a proposal though.

Indexing with enums and string literals (#2491, #7656)

  • This is a problem and we need to address it.
  • Unions will likely get priority and then we want to carry that to enums.

Numeric Literal Types (#7480)

  • Not drastically different form string literal types.
  • Currently has some strange behavior for flow of arithmetic on types.
  • Need to look at implementation.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Apr 15, 2016
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant