From: "zverok (Victor Shepelev) via ruby-core" <ruby-core@...>
Date: 2024-10-01T08:24:22+00:00
Subject: [ruby-core:119378] [Ruby master Feature#20770] A *new* pipe operator proposal

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/
 ______________________________________________
 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/