Idea for TypeScript constructor improvement

Problem Statement: In TypeScript 1.1, there are two basic ways to initialize complex properties with strong typing via a parameterized class constructor. Both have disadvantages. I will illustrate this with a simple example that uses Knockout, but this issue applies to any other JavaScript library that implements complex objects via initializer functions.

"Method 1" is to instantiate the properties outside of the constructor using a throw-away value, and then to set the desired value inside the constructor (see RightTriangle1 below). This method has the advantage of being rather simple to program/maintain because TypeScript automatically infers the property's type. However, this has the potential to cause ripple effects or performance issues at runtime because the code to instantiate each property is run at least twice.

class RightTriangle1 {
    public height = ko.observable(0);
    public width = ko.observable(0);
    public hypotenuse = ko.computed(() => {
        console.log("hypotenuse 1 calculated");
        return Math.sqrt(this.height() * this.height() + this.width() * this.width());
    });
    constructor(height: number, width: number) {
        this.height(height);
        this.width(width);
    }
}
var rt1 = new RightTriangle1(3, 4);
console.log("hypotenuse 1: " + rt1.hypotenuse());  // 5

Knockout happens to have an advanced feature to defer execution of a computed, but that's beside the point. Other libraries may not support such a feature and it's just one more thing for the developer to keep track of.

"Method 2" is to declare the properties with an explicit type outside of the constructor, and then to instantiate them inside the constructor (see RightTriangle2 below). This method has the advantage of eliminating the runtime double-instantiation issue, but it also eliminates the convenience of having TypeScript infer the types.

Method 2 has the drawback of extra work if a type is ever changed, but much worse than that, it places the burden on the developer to figure out what the type of each member should be. For trivial members (string, number, etc.) or libraries you've written yourself, this is merely busy-work, however for complex types used by a JavaScript library it is sometimes difficult to determine unless the developer is quite familiar with the library's definition. Lastly, this is just the sort of syntax that would make a JavaScript developer who was new to TypeScript think, "This is exactly what I was afraid of! Look at all that extra code I'm forced to write that just gets thrown away in the end!"

class RightTriangle2 {
    public height : KnockoutObservable<number>;
    public width: KnockoutObservable<number>;
    public hypotenuse: KnockoutComputed<number>;
    constructor(height: number, width: number) {
        this.height = ko.observable(height);
        this.width = ko.observable(width);
        this.hypotenuse = ko.computed(() => {
            console.log("hypotenuse 2 calculated");
            return Math.sqrt(this.height() * this.height() + this.width() * this.width());
        });
    }
}
var rt2 = new RightTriangle2(6, 8);
console.log("hypotenuse 2: " + rt2.hypotenuse()); // 10

In summary of the problem, "Method 1" begs performance or logic problems, and "Method 2" is too wordy.

Proposal: "Method 3" Fairly early on in the public life of TypeScript, the team added the ability to indicate retained fields by placing visibility modifiers on constructor parameters. I would like to propose adding a new feature to TypeScript to allow this idiom within the body of a constructor as well. This would permit compiling the code in the RightTriangle3 example below. Note the public modifiers on height, width, and hypotenuse.

class RightTriangle3 {
    constructor(height: number, width: number) {
        public this.height = ko.observable(height);
        public this.width = ko.observable(width);
        public this.hypotenuse = ko.computed(() => {
            console.log("hypotenuse 3 calculated");
            return Math.sqrt(this.height() * this.height() + this.width() * this.width());
        });
    }
}
var rt3 = new RightTriangle3(9, 12);
console.log("hypotenuse 3: " + rt3.hypotenuse()); // 15

With this proposal:

The RightTriangle3 class would have the identical JavaScript emit as RightTriangle2.
The RightTriangle3 TypeScript compile-time type interface would also be identical to RightTriangle2.
The developer is not required to separate the declaration of the property from its instantiation just to get strong typing when using a parameterized constructor.
The developer is not required to update the type of a property if the class interface ever changes - they can just update the initializer code.
The TypeScript code in RightTriangle3 is the most succinct of the three. RightTriangle1 is 12 lines long (besides being "wrong"), RightTriangle2 is 13, RightTriangle3 is just 10. Additional observable or computed properties in RightTriangle1 and RightTriangle2 add two lines of code each; with RightTriangle3 only one line of code is added each.
The TypeScript code in RightTriangle3 is still very close to the emitted JavaScript (and therefore unlikely to create future incompatibility issues).
The new syntax is also very similar to the existing TypeScript parameter property declaration shorthand.
The pattern demonstrated in RightTriangle3 enables a simple cut+paste migration path to implement a constructor (the developer would just have to paste in "this." on each line). With TypeScript 1.0, implementing a constructor is a lot more work because you have to manually convert RightTriangle1 to RightTriangle2 and explicitly write out the declaration of each member with its type.
There are no breaking changes; code that compiled in TypeScript 1.0 works without any modification in this proposed future version.

Specifics: Inside a class constructor function only, a visibility modifier (public, private, or protected) may modify a property on the instance variable this. If so, the line is considered a declaration of that property on the class and the type is inferred according to the normal TypeScript rules. The following example class A is legal under this proposal:

class A {
    constructor(property3: boolean) {
        public this.property1;  //any
        private this.property2 : string;  //string
        protected this.property3 = property3;  //boolean
    }
}

The above code is identical to this TypeScript 1.1 code:

class A {
    public property1;
    private property2: string;
    constructor(protected property3: boolean) {
    }
}

Use of a visibility modifier is otherwise not permitted within the body of a constructor. For example, class B below would be a syntax error because property1 is not qualified as a property of this. This condition should cause a new emit-preventing type error along the lines of Visibility modifiers within a constructor may only modify properties of "this".

class B {
    constructor(val: string) {
        public property1 = val;
    }
}

Use of a visibility modifier is similarly not permitted within a normal function member. For example, class C below would be a syntax error because in this proposal, class properties can only be declared in this manner within the constructor. This condition should cause a new emit-preventing type error along the lines of Visibility modifier declarations are only legal within the parameter list and body of a class constructor.

class C {
    doSomething() {
        public this.property1: string = "test";
    }
}

Use of the static modifier is similarly not permitted within a normal function member or the constructor. For example, class D below would be a syntax error because under this proposal, static class properties can only be declared using the existing TypeScript 1.0 syntax (within the body of the class). This condition should cause a new emit-preventing type error along the lines of Shorthand declarations may not be used on static properties.

class D {
    constructor(val: boolean) {
        public static property1: string = "test";
    }
}

What happens if a declaration occurs inside of a branch? For the purpose of the TypeScript type system, any branching, looping, etc. inside the constructor should be ignored. Furthermore, the JavaScript should be emitted exactly as if the public, private, or protected modifier were not present. Under this proposal, TypeScript should consider class E below to be valid. At compile time, TypeScript will consider class E to have a property called description of type string (even though at runtime the initialization code would never execute).

class E {
    constructor() {
        if (1 === 0) {
            public this.name = "";
		}
    }
}

What happens if there is a duplicate declaration and the types match? This should not prevent the emit. The second and successive duplicates should raise error TS2300: Duplicate identifier 'PROPERTY_NAME_HERE'. just like how existing duplicate declarations work.

What happens if there is a duplicate, but one is a subtype of the other or even if the types do not match? The same type resolution logic should be applied if the duplicates occurred as simple type declarations in the class body (outside the constructor). The second and successive duplicates should raise error TS2300: Duplicate identifier 'PROPERTY_NAME_HERE'.. This should not prevent the emit. This may incidentally result in downstream error TS2339: Property 'PROPERTY_NAME_HERE' does not exist on type 'THE_PROPERTY_TYPE'. wherever sub-properties of the property are used (just like in TypeScript 1.0).

In all other scenarios (such as with inheritance chains, subtypes, supertypes, assignability relationships, and generics), the same behavior as a class written like RightTriangle2 in TypeScript 1.0 should be used when evaluating what should happen with a class written like RightTriangle3 using the new shorthand syntax.

I believe that this syntax fits in nicely with both the goals and non-goals of TypeScript and I hope that you'll consider it or something similar. Thanks for reading this.

nycdotnet/idea.md