Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). austin (Austin Ziegler) wrote in #note-53:
AlexandreMagro (Alexandre Magro) wrote in #note-52:
austin (Austin Ziegler) wrote in #note-50:
It would *substantially* complicate parsing (one would only want to "assign" `_` if an expression *uses* it), and right now `_` is a valid variable name (if usually used for an unused parameter).
Using the "last expression result" as a global behavior could introduce unnecessary performance overhead, as the interpreter would need to track and update it for every expression.
Not necessarily. I don't know much about how the parser works to produce the AST, but if it is able to do a *small* bit of backtracking, it could detect the use of `_` (which would otherwise be an "unused variable") and mark the *previous* expression as requiring the last expression result. That would mean that the overhead would only exist when used. This sort of backtracking would be required with the use of `|>` in any case.
Furthermore, by explicitly using the pipe operator, the "last expression result" gains a clear meaning on its own, and no longer remains just an anonymous placeholder (`_`). This avoids the ambiguity that may arise in the code, which isn't an issue when writing expressions line by line in irb.
I don't entirely agree. The ambiguity still exists because there is (more or less) an implicit block behaviour. If `_` already exists in the current scope, *both* the use of a pipe operator and the implicit "last expression result" would potentially shadow or overwrite the use of `_`. (It may be a silly idea to use a variable called `_`, but it is *legal* to do so right now.)
Using the "last expression result" as a global behavior offers no real advantage over the pipe operator. The pipe operator provides a predictable and explicit structure: "Developer, the next expression depends on the result of this one." This clarity makes the code easier to read and follow. In contrast, treating the "last expression result" as a global behavior introduces the potential for confusing and poorly written code. It could lead to situations where, at first glance, a line of code appears self-contained, only to reveal midway through our mental evaluation that it depends on a prior expression. This undermines readability and makes debugging more challenging, especially in larger or collaborative codebases. The IRB has this behavior, but there we are debugging line by line. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110804 * Author: AlexandreMagro (Alexandre Magro) * Status: Open ---------------------------------------- Hello, This is my first contribution here. I have seen previous discussions around introducing a pipe operator, but it seems the community didn't reach a consensus. I would like to revisit this idea with a simpler approach, more of a syntactic sugar that aligns with how other languages implement the pipe operator, but without making significant changes to Ruby's syntax. Currently, we often write code like this: ```ruby value = half(square(add(value, 3))) ``` We can achieve the same result using the `then` method: ```ruby value = value.then { add(_1, 3) }.then { square(_1) }.then { half(_1) } ``` While `then` helps with readability, we can simplify it further using the proposed pipe operator: ```ruby value = add(value, 3) |> square(_1) |> half(_1) ``` Moreover, with the upcoming `it` feature in Ruby 3.4 (#18980), the code could look even cleaner: ```ruby value = add(value, 3) |> square(it) |> half(it) ``` This proposal uses the anonymous block argument `(_1)`, and with `it`, it simplifies the code without introducing complex syntax changes. It would allow us to achieve the same results as in other languages that support pipe operators, but in a way that feels natural to Ruby, using existing constructs like `then` underneath. I believe this operator would enhance code readability and maintainability, especially in cases where multiple operations are chained together. Thank you for considering this proposal! -- https://bugs.ruby-lang.org/