Use same parameters names when constructing a delegate from a function

[lucasteles]

Use same parameters names when constructing a delegate from a function

When we construct a delegate from an existing function de parameter names are not used in the body of the delegate, but if we use a lambda directly in the delegate constructor it will have the arguments with the same name as the lambda.

I catch this behavior when using minimal api's, which broke the parameter binding

open System
open Microsoft.AspNetCore.Builder

let builder = Environment.GetCommandLineArgs() |>  WebApplication.CreateBuilder
let app = builder.Build()

let inc1 (num: int) = num + 1
let inc2 = Func<_,_>(fun num ->  num + 1)

app.MapGet("/test1/{num}", Func<_,_> inc1) |> ignore // BadHttpRequestException: Required parameter "int delegateArg0" was not provided from query string.
app.MapGet("/test2/{num}", inc2) |> ignore // works

app.Run()

The existing way of approaching this problem in F# is to use just lambdas in every call.

Extra information

Estimated cost (XS, S, M, L, XL, XXL):

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[jl0pd]

It's a part of bigger problem #1083

[dsyme]

Closing as covered by #1083