Huh. I was just thinking about how cool a pipe operator would be in rust, and about method-chaining when I realized that they are both kind of the same thing! For example, look at these rust and gleam (a language with a very similar syntax):

+
//rust
+let result: Result<i32> = fallible_operation();
+let output = result
+  .map(add_one)
+  .map(add_one)
+  .map(add_one)
+  .unwrap_or(0);

+
//gleam
+let result: Result(Int) = fallible_operation()
+let output = result
+  |> result.map(add_one)
+  |> result.map(add_one)
+  |> result.map(add_one)
+  |> result.unwrap(0)
+

When they are formatted this way, don’t they look pretttty similar? That’s because, they are, by definition, the exact same thing. If you look into the function signatures behind any impl method/function in rust, they all start with an &self or some variation because the dot notation is actually just syntax sugar. If I wanted to write out the rust example the long way, I could’ve done it like this:

+
// the type of std::result::unwrap_or is fn(self, F) -> Result<U, E>,
+// but in dot notation the first argument is omitted, like in a pipe operator
+
+let result: Result<i32> = fallible_operation();
+let output = std::result::Result::unwrap_or(
+  std::result::Result::map(
+  std::result::Result::map(
+  std::result::Result::map(&result, add_one), add_one), add_one),
+  0);
+

And the pipe operator in so many functional languages also serves the same purpose: as syntax sugar. Anyways, I just found this kind of neat, and my guess as to a little bit about why there isn’t a pipe operator in rust yet, despite taking so much heavy influence from functional languages like OCaml.

+