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 3/25/2016 #7689

Closed
DanielRosenwasser opened this issue Mar 25, 2016 · 0 comments
Closed

Design Meeting Notes for 3/25/2016 #7689

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

Comments

@DanielRosenwasser
Copy link
Member

this-types for functions (#6739)

  • Defines ability to define type of this for the scope of a function.
  • If you're in a class, this is assumed to have the type of the class itself.
    • You can still override this by giving an explicit type to this.

Strict this checks

  • Problem: cognitive burden by creating a distinction between types of methods and properties with function types.
  • Looked at performance against master.
    • Lots of variance.
    • ac9f15b5
    • But does look like there is a consistent perf hit.
    • <10%, >5%.
  • Incompatible with old code in some cases.
    • Need to update .d.ts files.
    • Huge undertaking.
    • Already tons of stuff for
  • Options in light of this.
    • We can take neither.
    • We can take the backwards-compatible stuff, forget the strict this checking.
    • We can take both, and give people a heads up that there's going to be a perf hit for strict this checking.
  • Conclusion: hold off on strict-this.

No implicit this

  • Should we have that?
    • Yes!
  • Should it be part of noImplicitAny?
    • Well that breaks code.
    • You'd need a suppressing flag.
    • Nobody likes that, so noImplicitThis would not be umbrella'd.

Library modularization (#6974)

  • Background: hard to say what environments will have what at runtime.
    Our libraries try to be all-encompassing.

    The workaround has been to modify lib.d.ts on your own, but nobody wants to do that.

  • Current solution: granular libraries.

  • What about ambient decorators?

    • Let's come back to that.
  • You have es6.array.d.ts, es6.collection.d.ts, etc.

  • New --lib flag, takes a list of options.

    • You can still just specify es6 as the lib as an aggregate flag (include es6.*.d.ts).
    • Also have an es7.d.ts for all one functions that were added to ES7.
    • --target toggles the default if --lib isn't specified.
      • --target es2015 still includes lib.es6.d.ts.
    • What about ES2015? ES6 technically doesn't exist.
      • Everyone hates the official name.
      • We have no choice. ¯_(ツ)_/¯
  • So by default, you get the ES3 lib?

    • Sort of. It's more like ES5.5. We haven't split out the ES3/ES5 stuff.
      • Why?
      • Backwards compatibility.
    • So due to back-compat, is DOM always in lib.d.ts?
      • Yes?
      • But you can just use --lib es5 and add from there on.
        • To add to that, you make it --lib es5,dom.
      • But we could always add --lib node.
  • What about granular transformations?

    • People want async/await because Node has it, but as soon as you try to do ES6 emit, you run into problems like Node not supporting destructuring.
    • That's the next step.

Conditional compilation stuff

  • We're not fully committed to this.

Granularity

  • The granularity is great.
    • But there are some clear defaults.
    • Are there situations where people need all this granularity?
    • Can overwhelm users, can become a maintenance headache.
    • Let's keep these split up, not commit to them just yet.

Control Flow Analysis For Everything (#2388)

  • Background:
    • We needed reachability analysis.
    • Now we need control flow-based type analysis.
  • Now, we've subsumed reachability analysis with our work on control flow-based type analysis.
  • We now track all assignments and type-guards.
    • Assignments are now considered type-guards themselves as well.

Consider

function countLines(text: string[]) {
    let count: number;
    for (const line of text) {
        if (line.length !== 0) {
            count = count + 1;
        }
    }
    return count;
}
  • Our new checks will now yell at you for forgetting to initialize count and not informing us that count could be undefined.

  • Even if you initialize it at the wrong point.

    function countLines(text: string[]) {
        let count: number;
        for (const line of text) {
            count = 0; // not good enough - this loop might never execute!
            if (line.length !== 0) {
                count = count + 1;
            }
        }
        return count;
    }
  • We also infer correctly from falling through.

    function countLines(text: string[]) {
        if (text) {
          let count: number = 0;
          for (const line of text) {
              if (line.length !== 0) {
                  count = count + 1;
              }
          }
          return count;
        }
    }
    • countLines has type number | undefined since you implicitly returned undefined.

Assignments as a new type guard point

declare function getNumberOrString(): number | string;

var x = getNumberOrString(); // has type 'number | string'

if (typeof x === "string") {
    x;          // has type 'string'

    x = 1000;   // still okay to assign a 'number'

    x;          // has type 'number'
}

Shortcomings

Array accesses

Technically we should be introducing undefined from array indexing, but this would be such a massive pain for users that we can't consider this path.

Variable capture in closures

We don't track usage of a variable's use within a function.

function uh_oh() {
    return s.slice();
}
var s: string;
uh_oh(); // no error.

Potential for other work

  • Could we use this logic for checking for this before super, etc.?
    • Yes!
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

2 participants