Hello,
First off, I appreciate the work that has gone into this RFC.
I like the general direction and I am not fully against the idea. That said, I
am hesitant to introduce another way to express the same thing, especially when
it affects readability.
Speaking only for myself, I agree with Rob’s point that I expect return to
appear on the left side. Placing return on the right side inside the pipe makes
the statement harder to scan and can be confusing at first glance.
More importantly, I do not think the responsibility for returning should live
inside the pipe. Returning is control flow, while the pipe’s core purpose is
transforming data. With this change, the pipe no longer clearly communicates
“transform this value,” but can instead become responsible for ending
execution. I would rather see the pipe produce a result, and keep the return
outside the pipe so the intent stays explicit.
Also, while the example below obviously would not work, it highlights the
potential ambiguity this introduces. In a long pipeline, it becomes less clear
where returning happens and what role the pipe is playing.
function giveMeFourtyTwo() {
return 42
|> return;
}
Also if you put this into the short `fn` syntax. It will break for the same
reasons as above.
fn () => 'hello world'
|> strlen(...)
|> return;
Regards,
Jordi
