Private properties should still emit type

[AnyhowStep]

TypeScript Version: 2.7.0-dev.20171229

Code

class Gen <T> {
    private x : undefined|T;
}

Expected behavior:

declare class Gen<T> {
    private x: undefined | T;
}

Actual behavior:

declare class Gen<T> {
    private x;
}

The problem comes when trying to use such a class from another package.

import {Gen} from "some-package";

let a = new Gen<number>(9001);
let b = new Gen<string>("Hello, world!");

a = b; //OK
b = a; //OK

The assignment is okay because x is any in the generated declaration, making both Gen<number> and Gen<string> assignable to each other, when they shouldn't.

---

A more concrete example is something like this,

export class Builder <CanBuild extends boolean> {
    private _dummyCanBuild? : CanBuild;
    private amount? : number;
    private constructor (amount? : number) {
        this.amount = amount;
    }
    public static Create () {
        return new Builder<false>();
    }
    public setImportantValue (amount : number) : Builder<true> {
        //Set some important value
        return new Builder<true>(amount);
    }
    public build (this : Builder<true>) : number {
        //Return some stuff
        if (this.amount == null) {
            throw new Error("You should not have been able to call build()");
        }
        return this.amount;
    }
}

It works fine in the package that declares it. But packages that use it will see private _dummyCanBuild : any, making Builder<true> and Builder<false> assignable to each other. This would allow the user of the package to call build() without having called setImportantValue().

---

[DanielRosenwasser]

That's pretty gnarly, and admittedly not something I'm sure we discussed back in #1532 and earlier.

[AnyhowStep]

The temporary fix I use is to just have public readonly _dummyXXX? : GenericType|undefined for classes that need the type-safety, and are being used in other packages.

But this problem had plagued me, on and off, for a pretty long time, before I finally discovered the cause. I never thought to look at the type declaration file before!

I would have this assignable-when-it-should-not-be problem for some projects and not on others, and couldn't see a pattern to reproducibility. So, I never brought it up.

[RyanCavanaugh]

We can't really change the emit behavior as it stands because private properties are currently allowed to refer to types which are visible in the source file but not in the .d.ts file, so it'd be a big breaking change to start emitting the type. Due to some architectural issues it's not feasible to only emit the type when a) it's fully "nameable" in the current .d.ts scope and b) contains a reference the generic type parameter.

Without an extant property, we can't properly measure the variance behavior of the generic parameter, so just assuming that Foo<T> has "some" T isn't sufficient either.

If T is only in private positions then the only observable unsoundndess of a wrongly-typed class instance would be passing a Gen<T> to a Gen<U>'s public method and doing cross-instance private access.

This bug is about as old as TypeScript itself and this is the first we've heard of it, so asking the rare cases to add the workaround property (which can be protected BTW) seems good enough. Thanks for reporting it, though.

[AnyhowStep]

protected sounds way better.