Skip to content

error TS2385: Overload signatures must all be public, private or protected. Why? #7577

Description

@0815fox
public myMethod();
private myMethod(Data?:T,FromRevision?:number,TilRevision?:number);
public myMethod(Data?:T,FromRevision:number=0,TilRevision:number=0) {
  ...
}

gives:

error TS2385: Overload signatures must all be public, private or protected.

What is this restriction needed for? Of course a possible workaround is an internal helper function:

private myMethodInternal(Data?:T,FromRevision:number=0,TilRevision:number=0) {
  ...
}

public myMethod() {
  this.myMethodInternal();
}

But it is just unnecessary work and unnecessary function calls (performance, when called often).
Even worse, when i try to do this on a constructor, it complains:

error TS1089: 'private' modifier cannot appear on a constructor declaration.

Why not? I wanted to have a constructor, which is only accessible by methods inside the class and allows to specify additional parameters to the constructor, which would else hold their default values. Of course, the workaround above also works in this situation.

Activity

  1. mhegazy commented on Mar 18, 2016

    @mhegazy
    Contributor

    Constructor visibility is now supported in typescript@next. please see #6885

    As for visibility on signatures, the type system is TypeScript is structural, it is not clear what it means to compare two types with signatures that might not match in visibility.

  2. aluanhaddad commented on Apr 26, 2016

    @aluanhaddad
    Contributor

    Since there is no function overloading in JavaScript, there is only ever one method to call. From an api design perspective, your usecase makes sense, but as visibility modifiers in TypeScript are essentially a design time illusion, although there may possibly be support in a future version of ECMAScript,

  3. aluanhaddad commented on Apr 26, 2016

    @aluanhaddad
    Contributor

    Accidentally hit enter:
    From an api design perspective, your usecase makes sense, but as visibility modifiers in TypeScript are essentially a design time illusion, although there may possibly be support in a future version of ECMAScript, I think this restriction makes sense.

  4. 0815fox commented on Apr 26, 2016

    @0815fox
    Author

    Are you sure? I mean, there is lots of stuff, which is just a design time illusion. What I would like to achieve with that is, that tsc checks, that I can only call public signatures from outside of a class, while I can also call private signatures from inside the class and protected ones from inside a child class.

  5. mhegazy commented on May 20, 2016

    @mhegazy
    Contributor

    It is not clear there is much value for such feature vs the complexity added to the language and the implementation.

  6. locked and limited conversation to collaborators on Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    QuestionAn issue which isn't directly actionable in code

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions