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/