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.