I suggest we ...

Optional and named parameters on let bindings on modules

Optional and named parameters are supported in static methods, but not in let bindings on modules. This many times forces you to use a static class instead of a module, which has some inconvenients. Ocaml has this, so I'm guessing is doable.

131 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Gustavo Guerra shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Alfonso Garcia-Caro commented  ·   ·  Flag as inappropriate

    Having this will be tremendously beneficial when parsing TypeScript files to be used by Fable. Currently an extra type must be created to translate module functions in TypeScript with optional or ParamArray arguments.

  • Eric Stokes commented  ·   ·  Flag as inappropriate

    Coming from OCaml this is by far the thing I most want in F#. I am often forced into using a static class when what I really want is a module containing a type and some operations on that type. I'm not sure I agree that OCaml's optional/labeled implementation is "too powerful", for example curried optional arguments could be very useful in a pipeline, it seemed if we forced them to be tupled we'd mostly lose that.

  • Richard Minerich commented  ·   ·  Flag as inappropriate

    Also, would we allow overloading in the context of these special module functions? If not it's still not a replacement for actual static classes.

  • Richard Minerich commented  ·   ·  Flag as inappropriate

    It seems like this might ruin the symmetry between tupled function parameters and actual tuples, unless it could be that when you create tuples you can do the same thing, and that seems to come with a host of other problems. What if you could describe function parameters more like records and extend records to allow optional construction parameters?

  • trek42 commented  ·   ·  Flag as inappropriate

    Does named parameters have similar drawbacks as optional parameters (mentioned by Jon)? If not, would definitely see named parameters supported for curried let-bound functions.

    This would remove a fairly common annoying case in pipelines, where I find myself having to use lambda expression (e.g. "... |> fun param -> someFunc a b param c) instead of partial application ("... |> someFunc a b c"), because the pipelined variable isn't the last argument of the function. With named parameter I can use the parameter name to override the parameter order, at the same time increases clarity of code.

  • Jack Pappas commented  ·   ·  Flag as inappropriate

    OCaml does have this, so it is possible -- but as Jon H. pointed out, it's very easy to make this feature "too powerful" and ultimately cause more problems than it solves.

    +1 for Jon's suggestion that if this were implemented, it should only be for let-bound functions using the tupled argument style. I think that would provide a good compromise because you'd be able to write let-bound functions in modules in exactly the same way you're writing methods in static classes now (sans overloading), without introducing the complexity of optional curried arguments or type inference when using named arguments.

  • Jon Harrop commented  ·   ·  Flag as inappropriate

    OCaml is rather grim in this respect. They got too fancy and let you have optional curried arguments that support partial specialization which leads to all kinds of inconveniences.

    I would like optional non-curried arguments to let-bound functions though.

  • Andrew Cherry commented  ·   ·  Flag as inappropriate

    A fairly similar syntax of let functionName ?(parameterName: [type]) () = [...] seems like it would work if parameterName became type option? That would seem like it would fit with defaultArg still, etc...

F# Language

Feedback and Knowledge Base