I would love this feature, and I am not alone. Does anyone have a status/summary on this? The discussion is too technical at several points for me to follow.
It seems like perfect is being the enemy of the good, and that is such a shame for such a highly-requested feature. Would it be possible to reach a consensus based on some type of voting?
I also cannot speak for all the technical language discussions in that PR but as a user i would love that feature too. So IMHO this would enhance my programming experience in Julia.
The end of the discussion mentions a test PR by Simeon (https://github.com/JuliaLang/julia/pull/40860). So, work is being done but it looks like this functionality would break many packages
The original version of the functionality in the PR (a Scala-like ātight-bindingā syntax) was not breaking because it did not change the AST (and it only affected code that is currently an error).
The thing that is breaking is to try to implement a more expansive binding of the underscore by inserting new AST nodes.
Iām definitely in favor of the PR in its original version. Then maybe in 2.0 we can get rid of the special currying methods for >, ==, startswith, etc.
Came also across this PR the other day. Certainly a feature I would love to see. More so since the base R pipe which has been added in R 4.1 will supposedly support an underscore operator with the same functionality in R 4.2 (would be neat to have roughly the same base piping functionalities in both languages without extra packages).
I was looking for it, but couldnāt find it (but I also have heard, and not read about it iirc). I spent some more time checking and so far no changes to the pipe implementation have been made in 4.2 dev if I can tell correctly (usually I am not that deep into language internals). https://github.com/r-devel/r-svn/blob/master/src/main/gram.c
Is there still interest in this? Since it was removed from the 1.x milestone 9 days ago.
I think itād be an absolutely fantastic feature, improving readability and elegance of code. To me personally, itās also a big step towards julia really feeling like a functional language.
Itās hard to work on it without getting clear buy-in from the core devs on the semantics.
Personally, I favor the Scala-like ātight-bindingā semantics of the original PR, which is backwards-compatible, simple to explain and reason about, and gives clear improvements in simple cases (while for everything else you can use ->).
Every attempt to devise a more expansive DWIM syntax (to handle compound expressions like 1 + 2_) led to confusion, breakage, and ultimately ground progress to a halt.
If _ is too issue prone and \bullet doesnāt cause these issues, which I donāt know if it does, it should be worth a look. In my experience most would agree that readability of code is a great objective, far more important than typing a bit less, and this could bring julia code a lot closer to concise math notation at possibly no cost.
Personally, Iām pretty sure Iād prefer that no feature like this gets accepted. It would complicate the language, and I, for one, donāt see any benefit. Lately Iāve even stopped using anonymous functions, preferring to always give closures a name, to achieve a better debugging experience and better error messages. Furthermore, having a multi-line method definition allows for more granular code coverage.
The aforementioned readability of code, at least for the (relatively numerous) supporters of the feature, would be the obvious benefit. Since using the feature would, by its design, be optional, you would not be hindered in continuing to write your code in your preferred style.
Yep, this isnāt going anywhere. When it comes to currying or piping, thereās always massive threads with people arguing over everything, and in the end nothing happens. People want such a feature, but thereās no consensus. Do we at least agree that currently the |> operator is underpowered? Probably not.
Thereās a lot of support for the syntax in vague concept, but every time a concrete proposal gains some momentum, all those very same people who are so eager for the feature end up killing it by each proposing their own pet variations. We tried at some point to add the relatively uncontroversial āargless lambda syntaxā eg -> _[_] but that too was killed off by some people insisting that multiple instances of _ should all refer to the same argument rather than different ones for each occurrence. Never mind that this makes the construct far less useful and general, but this is the pattern: we start getting somewhere and then everyone and their uncle chimes in with different opinions about the details and that kills the momentum and we get nothing.
You make a valid point, but I think that if the proposal had some merit, it would go through, no matter how many random comments it gets. At the end of the day, the Julia devs have the power to decide.
I think it has been going in circles because it ends up adding very little to the language from a general perspective: we are talking about saving a few characters compared to closures. Meh.
For me, the fact that this PR has stalled is a sign of how healthy the mindset of the core devs is when it comes to language design. I have always been suspicious of languages that focus on syntactic bells and whistles. Julia never had this fixation with magical syntax for various special cases, and it is great that it is kept that way.