Issue #20770 has been updated by nobu (Nobuyoshi Nakada). Tracker changed from Bug to Feature ruby -v deleted (3.3.5) Backport deleted (3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN) In the previous trial syntax, the receiver of RHS was the result of LHS. In your proposal, the receiver of RHS is the same as LHS, and the LHS result is passed as an implicit argument? ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109947 * 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/

Issue #20770 has been updated by shuber (Sean Huber). I would still love to see this type of pipeline functionality implemented with plain expressions instead of new operators. I have this (old) working [proof of concept](https://github.com/lendinghome/pipe_operator#-pipe_operator) gem from years ago (basic syntax described below) but it was primarily focused on constant interception. I imagine it can be quite a bit more complex adding support for calling Proc objects and other edge cases. ```ruby "https://api.github.com/repos/ruby/ruby".pipe do URI.parse Net::HTTP.get JSON.parse.fetch("stargazers_count") yield_self { |n| "Ruby has #{n} stars" } Kernel.puts end #=> Ruby has 22120 stars -9.pipe { abs; Math.sqrt; to_i } #=> 3 [9, 64].map(&Math.pipe.sqrt.to_i.to_s) #=> ["3", "8"] ``` Most of the logic in that proof of concept was related to intercepting method calls to ALL constants which wouldn't be necessary if it was a core part of the language. The actual "pipeline" functionality (`PipeOperator::Pipe` and `PipeOperator::Closure`) is pretty simple - basically just keeping an array of constant+method+args calls and `reduce`ing the result when the pipeline ends. The proof of concept is basically `prepend`ing a version of every method in every constant with something like the example below in order to support this "pipeline expressions" syntax: ```ruby define_method(method) do |*args, &block| if Pipe.open Pipe.new(self).__send__(method, *args, &block) else super(*args, &block) end end ``` https://github.com/lendinghome/pipe_operator#-pipe_operator ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109952 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). bkuhlmann (Brooke Kuhlmann) wrote in #note-4:

For background, this has been discussed before:

- [15799](https://bugs.ruby-lang.org/issues/15799): This was implemented and then reverted. - [20580](https://bugs.ruby-lang.org/issues/20580): This recently popped up as well. - There are probably other issues that I'm forgetting about that have been logged on this subject.

Introducing `|>` as an operator that works like `#then` would be interesting and would be similar to how Elixir works, as Alexandre mentioned. This is also how [Elm](https://elm-lang.org) works where you can elegantly use `|>` or `<|` as mentioned in the [Operators](https://elm-lang.org/docs/syntax#operators) documentation.

I also use something similar to how Sean uses a `#pipe` method with a block but mostly by refining the `Symbol` class as documented [here](https://alchemists.io/projects/refinements#_call) in my [Refinements](https://alchemists.io/projects/refinements) gem.

Also, similar to what Sean is describing, I provide the ability to *pipe* commands together without using `|>` by using my [Pipeable](https://alchemists.io/projects/pipeable) gem which builds upon native function composition to nice effect. Here's a snippet:

``` ruby pipe data, check(/Book.+Price/, :match?), :parse, map { |item| "#{item[:book]}: #{item[:price]}" } ```

In both cases (refining `Symbol` or using Pipeable), the solution works great and provides and implements what is described here using different solutions. All solutions are fairly performant but would be neat if the performance could be improved further if there was a way to optimize these solutions natively in Ruby.

One issue with `.pipe` is that it mixes two approaches: the object method chain (`lhs.rhs`) and passing the result as an argument (`rhs(lhs)`). This inconsistency can be a bit confusing because it shifts between the two styles, making it harder to follow the flow. in the `.pipe` version: ``` "https://api.github.com/repos/ruby/ruby".pipe do URI.parse Net::HTTP.get JSON.parse.fetch("stargazers_count") yield_self { |n| "Ruby has #{n} stars" } Kernel.puts end ``` With a pipe operator, we can achieve the same result in a more consistent and readable way: ``` "https://api.github.com/repos/ruby/ruby" |> URI.parse(it) |> Net::HTTP.get(it) |> JSON.parse(it).fetch("stargazers_count") |> puts "Ruby has #{_1} stars" ``` This keeps the flow of passing the result from one step to the next clear and consistent, making the code easier to read and maintain. The pipe operator doesn’t add any extra complexity to method calls and provides more flexibility regarding how the "piped" value is used, making it feel more natural in the Ruby syntax. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109977 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). vo.x (Vit Ondruch) wrote in #note-6:

Code like `add(value, 3)` is hardly some idiomatic Ruby. If it was Ruby, then you'd likely use `value.add(3)` or `value + 3`. Other examples of readable code are [here](https://poignant.guide/book/chapter-3.html). I can't see what is readable about the new operator.

Also, I'd say that `Math` module is bad example in general, because it seems to be influenced by commonly used math notation. But arguably, having something like `Math::PI.cos` or `3.14.cos` would be quite natural for Ruby.

I believe there’s a misunderstanding here. The example `add(value, 3)` is not intended to represent an idiomatic Ruby expression, like `value + 3`. Rather, it illustrates how a method call that modifies or processes a value would work within a pipeline. Using the pipe operator is helpful for showing the order of executions. For example, if you want to execute a function `f` followed by `g`, you could write: ``` g(f(x)) ``` However, it's easier to follow the order of executions (e.g., f and then g) when written like this: ``` x |> f |> g ``` In real-world scenarios, especially when working with APIs or complex transformations, it's common to prepare data step by step before reaching the final function. Instead of using intermediate variables, which might only be used once, the pipe operator offers a clearer and more efficient solution. For instance, consider fetching and processing data from a client API: ``` response = URI.parse(client_api_url) response = Net::HTTP.get(response) response = JSON.parse(response).fetch("client_data") puts "Client info: #{response}" ``` With the pipe operator, the same logic can be simplified and made more readable: ``` client_api_url |> URI.parse(it) |> Net::HTTP.get(it) |> JSON.parse(it).fetch(important_key) ``` This approach not only avoids unnecessary variables but also makes the flow of data through the pipeline much clearer. The pipe operator simplifies this pattern and ensures readability, without adding complexity to method calls. It also provides flexibility in how the "passed" value is used throughout the steps. Again, these are simplified examples of real-world problems, where the pipe operator can help streamline and clarify otherwise convoluted method chains. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109979 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). ufuk (Ufuk Kayserilioglu) wrote in #note-8:

You can also make the whole pipeline with just using procs: ```ruby (-> { URI.parse(it) } >> -> { Net::HTTP.get(it) } >> -> { JSON.parse(it) } >> -> { it.fetch("title") }).call(client_api_url) #=> "sunt aut facere repellat provident occaecati excepturi optio reprehenderit" ```

Yes, and it's also possible to achieve this with a chain of `.then`, which results in a similar structure. The idea of the pipe operator is to be syntactic sugar, bringing functionality from functional languages into Ruby without introducing any complexity, while maintaining ruby's simplicity. ```ruby client_api_url .then { URI.parse(it) } .then { Net::HTTP.get(it) } .then { JSON.parse(it).fetch(important_key) } ``` ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109981 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). jeremyevans0 (Jeremy Evans) wrote in #note-10:

We could expand the syntax to treat `.{}` as `.then{}`, similar to how `.()` is `.call()`. With that, you could do:

```ruby client_api_url .{ URI.parse(it) } .{ Net::HTTP.get(it) } .{ JSON.parse(it).fetch(important_key) } ```

Which is almost as low of a syntatic overhead as you would want.

Note that we are still in a syntax moratorium, so it's probably better to wait until after that is over and we have crowned the one true parser before seriously considering new syntax.

The idea of using `.{}` is really creative, but it feels somewhat unintuitive. On the other hand, the pipe operator is a well-established concept, which would ease adoption. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109983 * 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/

Issue #20770 has been updated by mame (Yusuke Endoh). When pipeline operator was proposed previously (#15799), we briefly spoke of the idea of a block notation without a closing bracket ([the meeting log](https://github.com/ruby/dev-meeting-log/blob/c908bf7e7be60af5c5feabb544541de...)). For example, ``` add(value, 3).then do |x|> square(x) ``` is interpreted as: ``` add(value, 3).then {|x| square(x) } ``` However, this notation is a bit outlandish, so it was never taken very seriously. Reconsidering it with the notation proposed in this ticket: ``` add(value, 3).then |> square(it).then |> half(it) ``` is handled as: ``` add(value, 3).then { square(it).then { half(it) } } # Or: add(value, 3).then { square(it) }.then { half(it) } # depending on the associativity of |>. I am not sure which is better ``` It might be a good idea that we specialize this notation only for a block that is so simple that we don't need to name the parameters. But personally, I also feel that: ``` value = add(value, 3) value = square(value) value = half(value) ``` is good enough. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109989 * 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/

Issue #20770 has been updated by vo.x (Vit Ondruch). Not mentioning, the example ignores error handling, which would be IMHO the biggest problem in real life example ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109992 * 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/

Issue #20770 has been updated by zverok (Victor Shepelev). vo.x (Vit Ondruch) wrote in #note-14:

AlexandreMagro (Alexandre Magro) wrote in #note-7:

To me it just demonstrates that the APIs are likely incomplete and don't provide methods for easy conversion. We have a lot of conversion methods such as `#to_str`, `#to_json`, ... But there is no implicit transition from having e.g. `String` object to `URI`. I'd rather see something like `client_api_url.to(URI)` which could be equivalent of `URI(client_api_url)`.

I don’t think it is realistic, generally. I mean, convert every `f(g(x))` to “`x` should have method `g`, and the result should have method `f`, so you can write `x.g.f` always (or in most widespread situations)”. Many possible cases _can_ be argued about, but 1) the argument would not necessarily demonstrate that API change is reasonable, and 2) even when reasonable, it is not always possible. Say, if we take the sequence that is mentioned several times already (string → URL → HTTP get → JSON parse), then both concerns apply: 1. `String#to_url` (or `String#to(URL)` might be reasonable; `#HTTPResponse#parse_json`... maybe too; but `URL#http_get`?.. Not everybody would agree. 2. Even if agreeing on adding all those methods in principle, what about using a different HTTP library or a different JSON parser, what’s the answer would be?.. Something like `URL#http_get(with: Typhoeus)` or `URL#typhoeus_get` added for every library? Adding local refinements to handle that depending on the library? What if the HTTP library used depends on dynamic parameters?.. So, while I agree that many APIs in Ruby have an intuition of the “object at hand has all the methods you need for the next step”, in large realistic codebases, it is not so (both technically and ideologically), and `then { DifferentDomain.handle(it) }` is a very widespread way to mitigate that. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109994 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). vo.x (Vit Ondruch) wrote in #note-18:

Right, this was far fetched and would not work admittedly. But that is why I proposed the `client_api_url.to(URI)`, because after all, this is IMHO mostly about type conversion. Why would I ever want to call something like `URI.parse(it)`? Why would I need to know there is `parse` method and why would I need to put `it` / `_1` multiple times everywhere and every time in different context.

Zverok was precise in his comment. I understand your point, but the idea of to(URI) introduces an inversion of responsibility, which can lead to dependency inversion issues — a poor practice in software design, especially when working with different libraries. It's unclear what you mean by `client_api_url` in this context since, in my example, it was simply a string. Having a .to method on a string seems generic and nonsensical. As for the question "Why would I ever want to call something like URI.parse(it)?", code is already written this way. The pipe operator doesn’t change the syntax but rather inverts the reading flow. Lastly, the pipe operator is a well-established concept that aims to streamline existing Ruby syntax, not alter it. ```ruby client_api_url |> URI.parse(it) |> Net::HTTP.get(it) |> JSON.parse(it).fetch(important_key) ``` This is so clean. It's just Ruby. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-109998 * 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/

Issue #20770 has been updated by ufuk (Ufuk Kayserilioglu). I tend to agree with @Dan0042 on this one, this seems to go against the nature of Ruby. In Ruby, an expression like `URI.parse(it)` is always eagerly evaluated, except when it is inside a block. This is not true in other languages; ones that make a distinction between `Foo.bar` and `Foo.bar()`, for example. This proposal, however, is adding a new conceptual context in which the evaluation would be delayed, which would be in a sequence of pipeline operators. I am not sure if I like that, to be honest. In contrast, I like @jeremyevans0 's suggestion to add syntactic sugar to `.then` method in the form of `.{}` which still keeps the block as the only construct that would delay the evaluation of methods, and it allows the use of numbered block parameters and/or `it` inside such blocks without any other changes to the language. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110001 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). ufuk (Ufuk Kayserilioglu) wrote in #note-21:

I tend to agree with @Dan0042 on this one, this seems to go against the nature of Ruby. In Ruby, an expression like `URI.parse(it)` is always eagerly evaluated, except when it is inside a block. This is not true in other languages; ones that make a distinction between `Foo.bar` and `Foo.bar()`, for example. This proposal, however, is adding a new conceptual context in which the evaluation would be delayed, which would be in a sequence of pipeline operators. I am not sure if I like that, to be honest.

Actually, with the pipe operator, `URI.parse(it)` is also inside a block, but the block is implicit. The block spans from the pipe operator itself to the next pipe operator or a new line, making it simpler and more concise without changing the evaluation flow. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110003 * 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/

Issue #20770 has been updated by zverok (Victor Shepelev). @Eregon this example (at least for me) is just an easy target for discussion (because it uses standard libraries, is easily reproducible, and demonstrates the multi-step realistic process that uses several libraries at once). I believe the point here is not “how it could be rewritten in non-flow-style,” but rather “many people in many codebases find flow-style useful, should we have a syntax sugar for it?” I can confirm that for me (and many colleagues who were exposed to this style), it seems a more convenient way, especially to structure business code or quick sketching. It also might have a positive effect on overall algorithm structuring: the code author starts to think in “sequence of steps” terms, and (again, especially in complicated business code developed rapidly) it provides some protection against messy methods, where many local variables are calculated, and soon it is hard to tell which of them related to which of the next steps and how many flows are there. I think it is also very natural to Ruby, considering one of the things we have different than many other languages is Enumerable as the center cycle structure, which supports chains of sequence transformations... So, `then` is just a chain of singular value transformations. But I think it is not necessary to prefer this style yourself to acknowledge others find it useful. (Well, alternatively, it could be a discussion like “nobody should do that, it shouldn’t be preferred/supported style,” but that’s another discussion.) ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110006 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). I strongly agree that new additions should be thoroughly evaluated and aligned with the philosophy of the language ("A programmer's best friend"). I've found the discussion so far to be very productive, and my opinion is that: I don't see `|>` as "an arbitrary combination of symbols". I believe the pipe operator is a well-established concept, predating Ruby itself, and symbolic usage to express certain expressions is already present in the language, such as `&:method_name` instead of `{ |x| x.method_name }`. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110008 * 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/

Issue #20770 has been updated by shuber (Sean Huber). I agree with @zverok and am not quite sold on the value of `|>` over the existing `.then{}` if we still have to explicitly specify implicit args like `it/_1/etc` (unlike elixir). I am intrigued by the `.{}` syntax though but wish it did more than behave as an alias for `.then{}`. What if `.{}` behaved more like this elixir-style syntax without implicit args? ```ruby # existing ruby syntax url .then { URI.parse(it) } .then { Net::HTTP.get(it) } .then { JSON.parse(it).fetch_keys("some", "keys") } .then { JSON.pretty_generate(it, allow_nan: false) } .then { Example.with_non_default_arg_positioning(other_object, it) } # proposed ruby syntax url .{ URI.parse } .{ Net::HTTP.get } .{ JSON.parse.fetch_keys("some", "keys") } .{ JSON.pretty_generate(allow_nan: false) } .{ Example.with_non_default_arg_positioning(other_object, self) } ``` ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110020 * 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/

Issue #20770 has been updated by zverok (Victor Shepelev). @AlexandreMagro I don’t think this analogy is suitable here. Of course, there are operators that aren’t convenient to use in chaining (though, I should admit to the sin of sometimes just using `the.chain.with.+(argument).like.that`, and it works and follows the existing Ruby semantics and intuitions, even if not to everybody’s liking). But my point was that the proposed construct is _specifically_ for easier chaining but doesn’t fall in line with any other Ruby’s tool for that. I think a comparison with Elixir demonstrates that. In Elixir, you’ll say, “see, whatever you need to do with the value, just do with more `|>`, it is all the same.” In Ruby, you say “when you work with collections, you do `.method` and blocks; when you work with methods object already has, you do `.method`; when you need debug print in the middle of the chain, you can `.tap { p _1 }` just like that... But oh, there is also this one nice operator which you can’t mix with anything but it is there too... And it also creates an invisible block like nowhere else, but it is just there for convenience and looking like Elixir, sometimes!” That’s the major drawback of the proposal in my eyes, and I fail to see a comparably major _gain_. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110024 * 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/

Issue #20770 has been updated by nevans (Nicholas Evans). I think there are good reasons to want a `|>` operator in addition to (or instead of) `.{}`, but `foo.{ bar it }` is intriguing syntactic sugar. I think I like it. I just noticed that [it was rejected by Matz](https://bugs.ruby-lang.org/issues/12760#note-17) when `#yield_self` was introduced. But perhaps (when the syntax moratorium has ended) time will have changed his mind? It does seem to have a natural connection to `foo.()`. _But_, I would strongly prefer for it to be an alias for `#yield_self`; ***not*** for `#then`. Maybe that's a subtle distinction. Many rubyists seem to treat `#then` as a pure alias for `#yield_self`. But they are _not_ perfect synonyms. When `#then` was first proposed, Matz specifically mentioned [that they have different semantics](https://bugs.ruby-lang.org/issues/14594#note-17):

It is introduced that a normal object can behave like promises. So the name conflict is intentional. If you really wanted a non-unwrapping method for promises, use `yield_self`.

In other words, we should not assume that every object implements `#then` the exact same way. I have a lot of async code that predates `Object#then`. From a purely linguistic viewpoint, when we're dealing with a object that represents a completable process, the English word "then" strongly implies that the block will only run _after_ the process has completed. So I treat `#yield_self` and `#then` the same way that I treat `equal?`, `eql?`, `==`, and `#===`. The fact that all of these behave more-or-less identically on Object is not determinative: classes _should_ override `#eql?`, `#==`, and `#===` to properly represent the different forms of equality. Likewise, `#then` _should_ be overridden for any object that represents a completable process. On the other hand, just like `#equal?`, `#yield_self` should _never_ be overridden, and it should only occasionally even be used. I will use `#equal?` or `#yield_self` when the _semantics_ fit, even if that particular object doesn't override `#==` and `#then`. E.g: ```ruby # runs immediately: so "then" is not appropriate Thread.new do do_stuff end .yield_self { register_task_from_thread it } # waits for `Thread#value`: so "then" is appropriate Thread.new do do_stuff end .then { handle_result it.value } async { get_result } # returns a promise .then {|result| use result } # probably _also_ returns a promise .value # unwrap the promise ``` I do think there is room for a `|>` operator that is yet another version of this, with slightly different semantics from both `#yield_self` and `#then`. But (concerning this proposal) I share @zverok's concern about creating "an invisible block like nowhere else". We should be _very_ careful about adding unique syntax for a single operator. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110084 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). mame (Yusuke Endoh) wrote in https://bugs.ruby-lang.org/issues/20781#note-9 at DevMeeting:

AlexandreMagro (Alexandre Magro) wrote in #note-8:

...

* Improves readability by transforming `p(q(r))` into a more natural `r |> q |> p`, matching how we think.

Do you mean `r |> q(_) |> p(_)`?

Yes, `r |> q |> p` was just an abstract notation to explicitly show the order of method calls. @mame I’m replying here because of the "DO NOT discuss then on this ticket, please." mention in the DevMeeting thread. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110449 * 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/

Issue #20770 has been updated by austin (Austin Ziegler). lpogic (Łukasz Pomietło) wrote in #note-36:

What if I need an intermediate result beyond the next step of the method chain?

Cases: ``` ruby def foo r |> q(_) |> p(_) return q_result # "q_result" should be the result of the second step of the chain end ```

``` ruby def foo r |> q(_) |> p(_, r_result) # "r_result" should be the result of the first step of the chain end ```

If you need an intermediate result for any reason, don't use a pipeline, or restructure your return values so that they are returning some sort of context object. In your examples, `#tap` and `#then` would be more useful: ```ruby def foo q(r).tap { p(_1) } end def bar r .then { [_1, q(_1) } .then { |(rr, qr)| p(qr, rr) } end def baz rr = r p(q(rr), rr) end ``` I use the pipe operator in Elixir extensively, but I don't think that I’ve seen a proposal that would really improve Ruby's syntax over `.then { … }` *except* the proposed `.{}` acting as syntax sugar for `.then {…}`. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110541 * 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/

Issue #20770 has been updated by lpogic (Łukasz Pomietło). @austin, @AlexandreMagro I understand that this is a creature from the functional world. However, I wonder whether the current proposal (statement operator) would allow for such a forms: ``` ruby def foo r |> (q_result = q(_)) |> p(_) return q_result end # or def foo r |> q_result = q(_) |> p(_) return q_result end def bar (r_result = r) |> q(_) |> p(_, r_result) end ``` ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110543 * 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/

Issue #20770 has been updated by baweaver (Brandon Weaver). I'd written on the previous iteration of the pipeline operator a while ago here: https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d The ending example of what I thought, at the time, was an ideal state of it was: ```ruby double = -> v { v * v } increment = -> v { v + 1 } 5 |> double |> increment |> to_s(2) |> reverse |> to_i ``` ...which mixed both methods and procs to effectively pretend that Ruby was a LISP-1 derivative language, if only for the sake of pipelines. I believe that given the LISP-2 nature of the language this would be confusing, and add complexity for not a lot of practical gain compared to the combination of `then` and `it`. Frequently what folks are looking for is a nicer way to say this: ```ruby def some_method(v) = v + 1 5.then(&method(:some_method)) ``` ...and there have been a few proposals in that spirit before like `.:`: ```ruby HTTP.get(some_url).then(&JSON.:parse) ``` ...which I still think is an interesting potential syntax, and when applied to some of the pipeline proposals may become something like this: ```ruby HTTP.get(some_url) |> JSON.:parse |> filter { |k, v| v.is_a?(Integer) } ``` But again, comparatively speaking there's not a lot of overhead to `then` and `it` in those cases: ```ruby HTTP.get(some_url) .then { JSON.parse(it) } .filter { |k, v| v.is_a?(Integer) } ``` ...except to add more syntax that may be unclear for newer Ruby programmers that will be very hard to find documentation for. Even if I would very much like a shorter way to say `Object.method(:something)` I debate if it would be wise. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110549 * 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/

Issue #20770 has been updated by lpogic (Łukasz Pomietło). baweaver (Brandon Weaver) wrote in #note-41:

Frequently what folks are looking for is a nicer way to say this:

```ruby def some_method(v) = v + 1

5.then(&method(:some_method)) ```

Some proxy object and method missing mechanism may be the way. Example: https://github.com/lpogic/procify ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110554 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). austin (Austin Ziegler) wrote in #note-40:

Ruby already *has* pipeline-like method, `#then`. If `|>` or `.{}` acts as syntactic sugar for `#then`, I don't see an issue here. If, internally, it’s turned into the effective equivalent of `__pipe1 = r; __pipe2 = q(__pipe1); __pipe3 = p(__pipe2); __pipe3`, I don't see an issue here. But under no circumstances do I think that the effective temporary assignments should be exposed or made available to method calls further down the pipeline or after the pipeline is complete. That's too much magic.

I agree with your point. It would indeed be “healthier” not to expose assignments made within the pipeline, as this could be handled as an exception, though I think it might depend on specific implementation details. However, it’s possible to do this with `.then`: ```ruby def bar r .then { [_1, q(_1)] } # <= keeping q(_1) value as _1[1] .then { |(rr, qr)| p(qr, rr) } end ``` Or ```ruby x = 5 y = nil x.then { y = x * 100 } # Here `y` should be previously defined y # => 500 ``` ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110558 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). lpogic (Łukasz Pomietło) wrote in #note-46:

I wonder if the pipeline operator with assignment wouldn't also be useful in everyday code:

``` ruby str = "ABC" str |>= _.reverse str # => "CBA"

a_simple_json = '{"key":"value"}' a_simple_json |>= JSON.parse _ a_simple_json # => {"key"=>"value"}

a = [{greeting: "Hello"}] a[0][:greeting] |>= "#{_} World!" a # => [{greeting: "Hello World!"}] ```

The pipe operator is well-known, but this type of operation with assignment is something I haven’t seen before, and I’m not sure of its precedence. The examples also don’t illustrate a strong need for it. ```ruby # 1 str = "ABC".reverse # 2 a_simple_json = JSON.parse '{"key":"value"}' ``` In the third example, a dedicated method would be more suitable, I believe a similar proposal was made here: https://bugs.ruby-lang.org/issues/20818 ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110609 * 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/

Issue #20770 has been updated by lpogic (Łukasz Pomietło). AlexandreMagro (Alexandre Magro) wrote in #note-47:

The pipe operator is well-known, but this type of operation with assignment is something I haven’t seen before, and I’m not sure of its precedence. The examples also don’t illustrate a strong need for it.

I wanted _str_, _a_simple_json_ and _a_ to be treated as variables, maybe method arguments but impossible to reduce to one line. The notation `a |>= b` could be considered syntactic sugar for `a = a |> b`. Please remember that most binary operators in Ruby have similar syntactic sugar (including `||` and `&&`). I don't see why the "pipe" operator should be an exception. I see the potential for such a feature in situations where we want to perform some operation on an object and replace it with the result. So far, only operations of type `foo.a = foo.a / b` can be written without explicitly referring to `foo.a` twice (`foo.a /= b`). Swapping the order of arguments or using a method instead of an operator breaks the notation. However, using a "pipe" with assignment would give us more freedom, since it would apply to any case where `foo.a` is on both sides of the assignment: `foo.a |>= b / _`, `foo.a |>= _.div b`. Perhaps this is not an essential issue for the idea itself, but I think it may have an impact on the direction of change. Another thing I think is worth considering is the conditional "pipe" operator. It could combine features of the "pipe" operator with the `&&`. Like "pipe" with assignment, it could prevent self-repeating in some cases. Let's assume its notation would be `&>`: ```ruby foo = Struct.new(:bar).new # Please assume the code above is immutable. v = foo.bar &> Integer.sqrt _ # No exception here as right side is evaluated only if foo.bar is not false nor nil. v # => nil ``` How can I put this more simply? ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110796 * 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/

Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). lpogic (Łukasz Pomietło) wrote in #note-49:

I wanted _str_, _a_simple_json_ and _a_ to be treated as variables, maybe method arguments but impossible to reduce to one line.

If these variables need to be explicit and cannot be reduced to one line, then you definitely don’t need the pipe operator here. One of the main goals of introducing the pipe operator is to **eliminate the need for intermediate variables** when they don't add clarity or purpose to the code. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110799 * 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/

Issue #20770 has been updated by austin (Austin Ziegler). 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.) ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110801 * 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/

Issue #20770 has been updated by rubyFeedback (robert heiler). Personally I do not think I would need this feature (I share mame's opinion here), but what has not yet been pointed out is the language streem by matz (https://github.com/matz/streem). Now, streem is not ruby and matz has not pushed streem for a while, but I believe the basic gist (idea) for streem is one based around using pipes as a filter for data. This may not mean much in regards to ruby and the issue here, and I think one small issue is that in ruby we kind of do data-filtering via .method calls on objects, so |> may be somewhat orthogonal to this (or, at the least some suggestions of what |> should do exactly in ruby), but I think if we include streem's goals into consideration then matz may be open to suggestions for |> being useful in one way or another. I actually like |>, oddly enough, although as mame stated, I think there need to be some key reasons for using |> other than looking pretty. Magro wrote:

The pipe operator provides a predictable and explicit structure

While I like |>, I think any proposal to cover |> needs to have a good use case. Perhaps there could be a set of suggestions in regards to |> and matz and the ruby core team may select one that seems the best in itself and the least orthogonal. (I think Elixir's use cases are a bit different, in ruby I feel I can just use .methods such as .select or .reject, so as said I think that use case, as mame pointed out, may be already covered, and for |> it may be better to have some key advantages over classical .method chaining.) ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-111266 * 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/