Preserve parameter names when a curried function is partially applied

[theprash]

Consider these two functions:

let function1 param1 param2 = param1 + param2
let function2 = function1 0

Running these definitions into FSI results in this:

val function1 : param1:int -> param2:int -> int
val function2 : (int -> int)

function2 loses the parameter name param2. I propose that the parameter name is preserved so that its resulting type looks like this instead:

val function2 : param2:int -> int

I'm using FSI output to illustrate this but it also applies to the F# compiler service so that we can see the parameter name in tooling.

I can see why the current behaviour exists as it was likely the simplest implementation, but I would find this feature useful as raw types often don't convey the meaning of a parameter and it's not practical to make wrapper types or type aliases for every function parameter.

[forki]

Bonus points for keeping the xml docs. But I'm not sure if this is possible.

[dsyme]

This is definitely in the language-suggestion category. F# doesn't propagate soft-metadata in this way automatically (or even semi-automatically, e.g. through an attribute), and there are both pros and cons to doing so.

[dsyme]

Closing as this would be a language suggestion

[smoothdeveloper]

@dsyme would it make sense to close similar issues while adding a label "up-for-a-language-suggestion"? This will allow to scavenge them a bit easier if one is to reformulate those as suggestions.

[dsyme]

@smoothdeveloper "Needs-RFC" is a close match. Some of those have been left open. You're right we should be labelling these

[smoothdeveloper]

I'm sensing, you know well, how to do it then, and that I am coming little late in this battle.

Just to push the reasoning farther, do we remove the "Needs-RFC" tag when a PR is merged in the other repository that points to an "Needs-RFC" issue?

I personally don't like finicking with ticket system, but it would be super cool, and useful for github customers, if such workflow were automagically inferred and suggested (or it would be a real mess, who knows).

I am just concerned the "still actionable" but closed issue will remain closed and that we reduce the likelihood of it being actioned.

Is the "open issue count", a hard metric that cause us to close issues?

[smoothdeveloper]

@theprash do you mind bringing this issue to https://github.com/fsharp/fslang-suggestions/

Also, please bring all other excellent suggestions.

[theprash]

@smoothdeveloper Sure. I've just done that.

[smoothdeveloper]

Thanks! we still need more of the excellent suggestions, but this tail of the bit is to be lazily evaluated 🙂