Skip to content

Design Meeting Notes, 5/20/2016 #8724

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 May 20, 2016 · 0 comments
Closed

Design Meeting Notes, 5/20/2016 #8724

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

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented May 20, 2016

never and void assignability

class Base {
    method() {
        throw new Error("Not Implemented");
    }
}

class Derived extends Base {
    method() {
        throw new Error("Not Implemented");
    }
}

Allowing duplicate identifiers across declarations (#8675, #8696)

  • Introduced stack into the Error interface.
  • We report duplicate identifier errors, even if the types are the same.
  • These augmentations are the same.
  • 👍, let's allow this.
  • Need to do checks for same modifiers (abstract, readonly, visibility).

super issues

Subclassing without calling super (#7285)

class MyElement extends HTMLElement {
    constructor() {
        return document.createElement('my-element');
    }
}
  • What is the behavior of the example?
  • Returns something that is an instanceof an HTMLElement...but not MyElement?
  • This is extremely odd. You aren't returning the instance you're constructing.
  • MyElement won't be in your prototype chain, you won't get the appropriate methods.
  • But this is an ES2015 issue.
  • Unclear what we do about this.

Using return value of super calls (#7574)

class Foo {
    x: number;

    constructor() {
        return {
            x: 1,
        };
    }
}

class Bar extends Foo {
    y: number;

    constructor() {
        super();
        this.y = 2;
    }
}

let o = new Bar();
console.assert(o.x === 1 && o.y === 2);

The actual behavior of this is that the assertion should not fail.
In reality, this takes on the value of { x: 1 } in Bar's constructor, since Foo returned it from its constructor.

  • Incurs an overhead.
    • This requires some wonky code to enable this scenario.
    • Everyone has to pay the price regardless of whether they use it.
    • Could we just do something like _this = _super.call(this) || this instead of a helper?
      • Seems like spec says behavior for primitives causes issues.
        • This is a very niche case.
    • We'd also have to return _this to maintain _this value.
  • "If we had attributes, people could hint the correct thing."

We need to think about this more.
This seems to be a large change for a somewhat niche scenario, but we should better understand the users of it.

Super as the first statement (#8277)

  • Perhaps we could fake this with definite assignment analysis?
  • Start with a "poison" type, super(/*...*/) gives you some sort of "antidote" type (any other type?), check if you still end up with the poisoned type.
  • People an always cheat by putting code in an arrow function.
    • Not a big deal, you're really trying at that point.

--target ES5 --module ES6

  • Emit in ES5, entirely except for module
  • Useful for Rollup.
    • Becoming an increasingly common tool.
  • Why do we have to provide this functionality? How does Babel do this?
    • There's a Babel plugin.
    • Well there's a TypeScript plugin too, but there are some issues with that.
  • Let's just try it out and see how it works out.

Switch to not type-check .d.ts files

  • Parse/bind .d.ts files.
  • Don't check them unless entities are referenced from those .d.ts files.
  • This means you might miss errors across files.
  • But would be much faster.
  • Angular and NativeScript both have said they'd like it.
  • Have to think of a name for this.
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