Design Meeting Notes, 10/02/2015

[RyanCavanaugh]

Linting

Linting is now turned on in the CI build 🎉

• Can we make TSLint part of the build?
  • Yes. Make it part of ‘runtests’

Simple reachability checks

• Done as part of the binder
• Cheap in terms of perf
• ~Couple hundred LOC
• Found two bugs in the compiler
• Has some checks for e.g. while(true), but nothing extra-fancy
• Does not include definite assignment
  • Need a faster implementation of Set to do this quickly
  • Suggestion: use a dynamic-implementation Set using bit masks for sets with fewer than 32 members
• How does a user opt in to this?
  • Good breaking changes: Code after 'return', for example, should be on by default
  • Controversial: No implicit return, no fall-through, etc.
  • What is our stance vs TSLint? e.g. ==, implicit ;, etc.
    • Type systems are kind of linty anyway
    • But we don't want to be in the business of style enforcement
    • What about plugins? Too complex. Maybe it can go in the Language Service, though?
• Currently four options:
  • noUnusedLabels (on by default)
  • noFallThrough (off by default)
  • noImplicitReturn (off by default)
  • noUnreachableCode (on by default)
• 'Strict' mode that combines some/all of these?
  • Nope
• How do we name these? noImplicitAny vs allowImplicitAny, allowUnreachableCode vs noUnreachableCode
  • What about implicitAny=false?
  • What about these names makes them obviously boolean?
  • noFoo / allowFoo pairs?
  • Can we standardize on no ?
  • Commandline parser doesn't allow non-true boolean flags
  • Take offline and endure bikeshedding in the interim
• 👍 in general

abstract enhancements

• In class expressions (Abstract class expressions #4578): No.
• export default abstract (Cannot 'export default' abstract, ambient class or interface #3792)
  • We limited this in the grammar to avoid keyword soup
  • What is this limit for?
    • export default is kind of like a declaration and kind of like an expression
  • Workaround is simple
  • Is anyone actually hitting this?
  • Refusal to come to consensus ...
• abstract properties (Abstract Properties #4669)
  • 👎 This doesn't make sense to us. The slot always implicitly exists; delegate to protected methods if you want to enforce a getter/setter contract
• Make abstract classes implicitly abstractly implement their base interface (Missing property declaration in abstract class implementing interfaces #4670)
  • Big convenience, but how do you get into this situation?
    • You are implementing ~half of some foreign interface
  • This is actually very confusing semantics when it comes to which members appear?
    • Properties? Methods? Properties with call signatures? We don't make strong distinctions here
  • Nothing appears on the prototype chain
  • 👎 due to unclear semantics around properties
• A way to enforce the static shape of a class (no issue)
  • e.g. class Foo { abstract static bar() { } }
  • We already lack a way to declare that a class (static side) or namespace implements some interface
    • Should explore this problem space first
  • Start with Allow a module to implement an interface #420
• abstract classes shouldn't require a super call (Suggestion: pure abstract classes shouldn't require 'super' call #4429)
  • e.g. only require classes with a declared constructor to call super
  • This is an ES6 requirement, so no
• Intersections of abstract constructor functions have construct signatures that aren't abstract (Instantiation of intersections not checked for abstract restriction #4559)
  • How does this function come to exist?
  • Not clear that this should always be abstract
  • Out of time

[denvned]

@RyanCavanaugh Regarding abstract properties, see my comment about why they are actually make sense. Workaround with delegating to protected methods requires more cluttered code, and have runtime performance overhead implications.

[mhegazy]

There is no distinction anywhere in the typeset stem between a getter/setter and a property declaration. So declaring an abstract setter for instance will not force the driver class to implement the property as a getter/setter pair.

[denvned]

@mhegazy Yes, I know that. That's why I'm actually proposing abstract property declarations, and not abstract getters/setters.

[denvned]

Today I can write:

interface A {
    p: number;
}
class B implements A {
    get p() { ... }
    set p(v: number) { ... }
}

But why should not I be able to write the following then?

abstract class A {
    abstract p: number;
}
class B extends A {
    get p() { ... }
    set p(v: number) { ... }
}

And forced to write the following instead:

abstract class A {
    get p() {
        return this.getP();
    }
    set p(v: number) {
        this.setP(v);
    }
    protected abstract getP(): number;
    protected abstract setP(v: number): void;
}
class B extends A {
    protected getP() { ... }
    protected setP(v: number) { ... }
}

[mhegazy]

The abstract here is irrelevant. in your example, adding an abstract modifier to a property declaration does not add any additional expressiveness, in the view of the type system, all these are equivalent:

abstract class A1 {
    p: number;
}

abstract class A2 {
    abstract p: number;
}


abstract class A3 {
    get p() { }
    set p(v) {}
}

abstract class A4 {
    abstract get p();
    abstract set p(v);
}

abstract class A5 {
    set p(v) {}
}

abstract class A6 {
    abstract get p();
}

all what the type system cares about is that there is a slot called 'p' on that type, and that it is a 'number'. getters/setters are not treated any differently from properties. moreover, there is no way to force a property to be implemented as getters/setter pairs. even missing a getter or a setter implementation does not affect that.

thus adding the abstract keyword will not add you any additional expressiveness, it will only save you from writing the body of a getter/setter functions but will not mean what you want it to mean. see #12 for more relevant discussion about setters/getters.

[denvned]

all what the type system cares about is that there is a slot called 'p' on that type, and that it is a 'number'. getters/setters are not treated any differently from properties. moreover, there is no way to force a property to be implemented as getters/setter pairs. even missing a getter or a setter implementation does not affect that.

As I already said, I know that. My point is that it should be possible to force a property to be not forgotten to be implemented by any means, not necessarily with getters/setters (but of course it will be usually implemented with getters/setters):

abstract class Prudent {
    abstract propertyYouMustNotForgetToImplement;
}
class Forgetful extends Prudent {
   // oops, I have forgotten something again
}

Here a compilation error should carefully remind us to implement the property. Without abstract it would be harder to achieve.

And when readonly will be here, we will be able to write abstract readonly someProperty;.

[mhegazy]

it should be possible to force a property to be not forgotten to be implemented by any means, not necessarily with getters/setters (but of course it will be usually implemented with getters/setters):

not sure i understand what you mean by "implemented". properties do not really exist in the emitted code. they are just a way for the type system to know the "shape" of your type. so whether you redclare them in the child class, or not, it has no functional impact.

I think what you are looking for is that the property is never null or undefined, i.e. initialized (either with a value, or a getter), as your base class have some dependency on its value, and this is tracked by #185

[denvned]

not sure i understand what you mean by "implemented"

We can implement a property by writing a custom getter/setter, or opt-out to the JavaScript default implementation, which is set/get a value associated with a key (property name) in a object.

properties do not really exist in the emitted code. they are just a way for the type system to know the "shape" of your type. so whether you redclare them in the child class, or not, it has no functional impact.

If you redeclare (implement) a property with a getter/setter then it actually exist in the emitted code, and obviously has a functional impact.

I think what you are looking for is that the property is never null or undefined

No, it is pretty much unrelated to what I am proposing.

Once more, abstract properties can make us sure that one of derived classes either implement a property with getter/setter, or consciously opt-out to the JavaScript "default implementation".

abstract class A {
    abstract p1;
    abstract p2;
    abstract p3;
    abstract p4;
}
class B extends A {
    get p1() { ... } // implement p1 with getter only

    set p2(v: number) { ... } // implement p2 with setter only

    // implement p3 with both getter and setter
    get p3() { ... }
    set p3(v: number) { ... }

    p4; // consciously opt-out to the JS default implementation for p4
}

Abstract properties can't enforce any of four alternatives above, but they can enforce that a property is consciously implemented in either way.

Abstract properties should work the same way properties declared in interfaces currently work.

[jbondc]

Appreciate the notes, happy you guys are limiting the abstract box {}, ☀️ weather.

[craigbroadman]

As discussed here.... #4669

An abstract property is precisely what I need for using lambda/arrow functions (as they are actually properties)

"Class 'Base' defines instance member function 'def', but extended class 'Concrete' defines it as instance member property"...

abstract class Base {
    abstract abc(): void;
    abstract def(): void;
}

class Concrete extends Base {
    private setting: boolean;

    public abc(): void  {
        this.setting = true;
    }

    public def = (): void => {
        this.setting = false;
    }
}