fsharp
non symmetricity between `fun` and `function` for tuple forces usage of parens
those are allegedly similar semantically:
fun a -> //...
function a -> //...
but for tuple, it doesn't work
fun a,b -> // error FS0010: Unexpected symbol ',' in lambda expression. Expected '->' or other token.
function a,b -> //...
I wonder if this can be fixed without ambiguity, because it would be an incomplete lambda in current version of the language and it would reestablish fuller symmetry with function construct.
The existing way of approaching this problem in F# is to use function or wrap with parens.
Maybe a code fix for putting the parens, or turning into function would make sense if we can't make this suggestion work / it is rejected on some grounds.
Pros and Cons
The advantages of making this adjustment to F# are semantically more consistent.
The disadvantages of making this adjustment to F# are may prevent other constructs in the future.
Extra information
Estimated cost (XS, S, M, L, XL, XXL): M
Related suggestions: (put links to related suggestions here)
Affidavit
Please tick these items by placing a cross in the box:
- [x] This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
- [x] This is a language change and not purely a tooling change.
- [x] This is not something which has obviously "already been decided" in previous versions of F#. I
- [x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
Please tick all that apply:
- [x] 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 :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.
fun and function are actually different.
fun expects a parameter list and a function body (where each parameter must be enclosed in parentheses if it is a pattern or has a type annotation), in the same way as a named function.
function expects match expressions, separated by '|'.
So the mentioned behavior makes sense.
Actually, I think the use of function should be discouraged in favour of proper matches, except for one-liners.
But for function one-liners you get a no-no from Fantomas :-(
No-no from me on discouraging the use of function. They are brilliant for multiple step transformations starting with a regular match to transform something and then doing another match on that result without having to think up a name to bind the intermediate result(s) to.
Basically, anywhere that an expression result needs to be the 'function' of some singular input value that can have multiple shapes. Without having to come up with a name and use it twice, redundantly, both times.
No-no from me on discouraging the use of function. They are brilliant for multiple step transformations starting with a regular match to transform something and then doing another match on that output without having to think up a name to bind the intermediate result(s) to.
Basically anywhere that an expression result needs to be the 'function' of some input value that can have multiple shapes.
to me also the tuple between fun and -> looks unambiguous enough to interpret it as function argument pattern,
but it may cause problems if fun will become optional #168
those are allegedly similar semantically:
fun a -> //... function a -> //...
Could you explain? To the best of my knowledge, the second line is invalid.
@LyndonGingerich in such case:
let data = [1,"1";2,"2"]
data |> List.map (function a,b -> a * 2)
data |> List.map (fun (a,b) -> a * 2)