Constructor Visibility

[AbubakerB]

Constructor Visibility

(This is a updated PR from #4174)

There wasn't any detailed proposal, so I'm just going to list what this PR implements.

1) Constructor Visibility

1. A constructor can now have the private or protected keyword on its signature.
2. All constructor overloads must be of the same visibility (i.e. all private, protected, or public)

2) Private Constructors

A class with a private constructor:

1. Can only be instantiated within it's own class.
2. Can only be extended within it's own class.

3) Protected Constructors

A class with a protected constructor:

1. Can only be instantiated within it's own class.
2. Can be extended.

4) Signature Assignability

• A public, protected and private signature is assignable to a private signature.
• A public and protected signature is assignable to a protected signature.
• A public signature is assignable to public signature.

[msftclas]

Hi @AbubakerB, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

[RyanCavanaugh]

This should be a one-directional relationship: public is assignable to protected and private, and protected is assignable to private (but none of the reverse)

[AbubakerB]

Done

[mhegazy]

how about:
Cannot extend a class '{0}'. Class constructor is marked as private.

[AbubakerB]

Done

[DanielRosenwasser]

Why is it just comparing the first of each? Why was this change made?

[RyanCavanaugh]

Only the first has to be checked because the rest must have identical visibility (it's an error for this not to be the case)

[AbubakerB]

Is there anything left for me to do on this?

[RyanCavanaugh]

@ahejlsberg - take a look?

[mhegazy]

Sorry for the delay, we will be discussing this in the TS design meeting tomorrow. should get back to you shortly after.

[mhegazy]

@AbubakerB, we have no more comments on the design. Please update for merge conflicts.

Just one comment a private constrictor should be visible within nested classes, we do not handle this for private and protected members today (see #7058).

[mhegazy]

as noted in , we #7059, if here is not sufficient, it should be a while loop walking up, looking at all enclosing classes, so that something like this should be legal:

class B {
    private constructor() { }

    method() {
        class C {
            method() {
                new B(); // should be fine
            }
        }
    }
}

[AbubakerB]

Done

[AbubakerB]

So now, a private and protected constructor can be instantiated and extended (already the case for protected) within the scope of its own class.

I also, hopefully, implemented it such that it'll be easy for #7058 😃

[AbubakerB]

Build is failing due to gitignore ignoring the tests/**/*.js.
There's an open PR to fix this - awaiting it's merge.

[RyanCavanaugh]

@AbubakerB thanks! This was a three-day weekend but we're back on Tuesday and should be able to take a last look.

[mhegazy]

@AbubakerB, one last merge conflict. but we should be good to go after that.

[AbubakerB]

Sure :)

[mhegazy]

thanks!

[mhegazy]

#7058 should be a 1-line fix as well if you are interested.

[mhegazy]

@AbubakerB, Since you implemented this feature, do you mind adding some documentation at https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Classes.md?

[AbubakerB]

Thanks guys ⛄ !

Sure, no problem

[myitcv]

This is a great change, thanks very much @AbubakerB and all involved

[wiredprairie]

Was point 4 regarding signature assignability completed as part of this PR? If so, is there documentation with an example? I couldn't find anything that seemed connected or related in the TypeScript Handbook.