function signature refactor, compiler needs prevent parameters of same type adjacent to one another and Any type

[wesleyolis]

Suggestion

Basically when you have a parameter of type Any and one refactors the function and adds a parameters to the left the change in the function signature, then all function calls, do not detect the insertion of a parameters, because the existing parameters, matches the next any type parameter.

The compiler should give a warning, when their is an overflow of supplied parameters to a function call, that last parameters are all of type any, because their is a high like hook, that their is a mistake.

What probably be better as well, is that any type parameters, must be supplied by name,
in which case they don't have to be the last parameter, but will ensure that if the name parameter position changes, can emit a warning, but existing functions could still compile correctly with out having to change a thing.

Larger pattern identical typed adjacent parameters, pit fall with refactoring, should be dis-allowed:

The best improvement actually since this is not just around the any type(worst), but if same type parameters before or after, when adding or removing when refactoring.

Improve the compiler to be more inteligent, to detect function signatures, were their are identical typed
parameters next to one another, to prevent anyone structuring function signatures like this,
they must rather take their parameters in via an interface in a key, value name pair fashion or possibly
in a name parameter passing manor.

This means that their be less need to have tests, to detect these problems and the compiler can defiantly ensure that when refactoring, correct function are bound to one another, which why we all love type languages, it ensure correct binding, wiring, piping of information between everything.

This pitfall potentially is in any language, so this would be a one up for typescript.
super strict mode.

Use Cases

function fun(a : bool, b : number, c : any, d : number =  0)
fun(true, 56, 99999, 11111);

Refactor function:

function fun(a : bool, b : number, z : number, c : any, d : number = 0)

fun(true, 56, 99999, 11111); // Still compiles, were want this to be an error(warning), cause no illogic parameters mappings.

Parameters required to be called by name, if adjacent parameter types are identical

function fun(a : bool, b : number, c : any, d : number =  0)
fun(true, b: 56, c : 99999, 11111);
function fun(a : bool, b : number, z : number, c : any, d : number = 0)

fun(true, b: 56, c: 99999, 11111); // the compiler can now detect, that their is a parameter miss match.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

[MartinJohns]

This sounds like named arguments, which was proposed several times and rejected. #467

[wesleyolis]

Well, I would look at it this way, its kind named arguments, only when their is ambiguity and it is their such that the compiler can only detect out of order parameters, it only does the checking part, no juggling of parameter ordering. So basically it loops thought each parameter, if detects identical adjacent types, then checks that these parameters, are call with their parameters name, thats it no fancy business of output different syntax or different ordering of parameters. It only does a type checking with an enhancement, that the name is mentioned is their ambiguity. Otherwise, its all just blow away when after type checking has been performed.

One could also look at implementing static analysis to detect this, but then their would be a problem, because with out the super strict typescript enhancement check, only thing can do is prevent function call, or request that comments be added. /param name/, which I see someone has suggested.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.