Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add implied void return-type and switch to fluent this return type #3776

Closed
wants to merge 2 commits into from
Closed

Add implied void return-type and switch to fluent this return type #3776

wants to merge 2 commits into from

Conversation

david-fong
Copy link
Contributor

@david-fong david-fong commented Jan 27, 2021

The kind of change this PR does introduce

  • a bug fix
  • a new feature
  • an update to the documentation
  • a code change that improves performance
  • other

Current behavior

  • Fluent method signatures return the type of the class.
  • Method return types are inferred especially when void.
  • Overloads do not specify a general-case type signature.

New behavior

  • Fluent method signatures return the type of the class, or the type of a derived class calling the base method.
  • Method return types are explicitly specified. I think this is an improvement in that it explicitly specifies intention, and the compiler will check that the function body doesn't violate that intention. Let me know if you would like me to revert this change.
  • General-case overload type signatures are specified. This prevents undesirable behaviour when using conditional types such as ReturnType. See this StackOverflow answer.

Packages that use TypeScript and depend on this package should not experience any breakage or new compiler warnings as a result of this change.

Other information (e.g. related issues)

https://www.typescriptlang.org/docs/handbook/advanced-types.html#polymorphic-this-types

I am motivated to make this change because I am working on a type-utility for socket.io that would enable stronger type checking for on and emit on both the client and server sides. It involves making interfaces that extend the Socket class. Without polymorphic this, I wouldn't be able to chain fluent methods such as on while keeping my extension-interface's special typings behaviour. Here is a discussion thread I started about this idea: #3777.

@darrachequesne
Copy link
Member

Merged as 9e8f288. Thanks a lot!

@darrachequesne darrachequesne added this to the 3.1.1 milestone Feb 3, 2021
This was referenced Mar 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants