[ruby-core:119466] [Ruby master Feature#20770] A *new* pipe operator proposal

["nevans (Nicholas Evans) via ruby-core" <ruby-core@ml.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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/