Support parameter types for mixin constructors

[Vakhurin Sergei (igelbox)]

This PR adds an ability to use strict constructor signatures on mixin classes for #13743 instead of saying just constructor(...args: any[]).

This feature will be useful if the mixin class needs some arguments from the overridden constructor, e.g.:

abstractclassBase{constructor(s: string=''){}}constmixin=<TextendstypeofBase>(base: T)=>classextendsbase{constructor(x?: string){super(x);// use the "x"}};classIncompatible{constructor(n: number){}}mixin(Incompatible);// Fails to extend from a class with an incompatible constructor

I researched for the reason of requiring the mixin constructor to be constructor(...args: any[]) but didn't manage to find one which can be violated by this PR.

[Ryan Cavanaugh (RyanCavanaugh)]

Vakhurin Sergei (@igelbox) is there an issue tracking this change?

[Vakhurin Sergei (igelbox)]

Ryan Cavanaugh (@RyanCavanaugh) no, there's no such issue.
Must I file one?

I just faced with this drawback during the development process and then I was glad to dig and fix the code. Filing issues isn't what I'm loving in software development)

[Ryan Cavanaugh (RyanCavanaugh)]

PRs do need issues tracking their changes.

If a PR just appears with some code changes in it, we don't know what's happening: What is the change trying to do? Is that change desirable? What are its goals? Is it going to be a breaking change? What's an example of code that motivates the change in the first place? Is there a better way to accomplish that task? Does the change actually accomplish that specific goal, or does it do something slightly different? Should some other larger change to the compiler be made instead?

There's a reasonably rigorous process for answering those questions for issues. With a PR, we have to work backwards from the code and baseline changes to determine the answers, which is then conflated and commingled with how the code itself works.

So, long story short, please don't put up PRs that don't have an associated issue tracking them. Our process is fairly lightweight here for straightforward things, but we do need contributors to play along in the process to help keep things moving along smoothly. Thanks!

[Nathan Shively-Sanders (sandersn)]

I'm cleaning up our PR backlog and this is one is fairly stale, so I'm going to close it.

Vakhurin Sergei (@igelbox) The next step is to create an issue since mixin types are fairly tricky and require a bit of design discussion, as well as thinking about backward compatibility, before implementation.

[TypeScript Bot (typescript-bot)]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.