Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add syntactic (_ + 1) sugar for functions ala Scala/Clojure #186

Closed
baronfel opened this issue Oct 20, 2016 · 2 comments
Closed

Add syntactic (_ + 1) sugar for functions ala Scala/Clojure #186

baronfel opened this issue Oct 20, 2016 · 2 comments

Comments

@baronfel
Copy link
Contributor

baronfel commented Oct 20, 2016

Submitted by Khan Thompson on 3/21/2014 12:00:00 AM
37 votes on UserVoice prior to migration

Add in shorthand syntax for anonymous functions, even if it is only for single argument functions.
For example:

[1; 2; 3; 4] |> List.map (_ + 1)

As opposed to

[1; 2; 3; 4] |> List.map (fun i -> i + 1)

It would be great to have this shorthand so that our anonymous functions are shorter than the C#ers' :).

Original UserVoice Submission
Archived Uservoice Comments

@dsyme dsyme removed the open label Oct 29, 2016
@dsyme dsyme changed the title Add syntactic sugar for functions ala Scala/Clojure Add syntactic (_ + 1) sugar for functions ala Scala/Clojure Oct 29, 2016
@charlesroddie
Copy link

charlesroddie commented Jan 1, 2020

Presumably g(f(_+1)) would mean g(f(fun i -> i+1)), resolving to the closest brackets, but g(f <| _+1) would mean g(fun i -> f(i+1)). People would find this confusing. It will be hard to find a bracketing rule that is both consistent and unsurprising. Even something simple like (_+(1+_)) I believe would generate a lot of interpretations. If the notation didn't use round brackets then this problem would go away, but F# currently restricts itself to ascii characters and all the suitable ones got taken straight away.

Some suggestions in #168 are intermediate approaches to the same problem (shorter syntax for fun x ->) which are more readable and don't give the same ambiguities.

@dsyme
Copy link
Collaborator

dsyme commented Jun 16, 2022

Treating this as a duplicate of #634

@dsyme dsyme closed this as not planned Won't fix, can't repro, duplicate, stale Jun 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants