There have been a couple of proposals about postfix syntax recently: https://github.com/rust-lang/rfcs/pull/2442#issuecomment-391562545 for postfix macros and Idea: Simpler method-syntax private helpers for calling free functions with method syntax with limited scope.
The motivation for both is to allow reading expressions from left to right.
There is a fair amount of pushback on both of these proposal because they allow things that look like method calls that aren’t method calls.
In both cases that particular objection could be overcome by introducing a different postfix syntax. Specifically, introducing an operator |> (bikeshed the actual symbol) such that
expr |> free_fn(a,b, c) would desugar to
free_fn(expr, a, b, c) and
expr |> my_macro!(a, b, c) would desugar to
my_macro!(expr, a, b, c). In the macro case, I’m not sure if it makes sense to evaluate the expression before passing it to the macro or not.
In reply to the post from @Centril:
So if I’m understanding you correctly, instead of . as the operator, something else? For example using |> as in F#: fun(receiver, args…) becomes receiver |> fun(args…) instead of receiver.fun(args…) and then for macros: receiver |> fun!(args…)?
Yes you understand correctly.
So I think such a solution costs more than reusing . syntax since . is already well understood – “all” you need to do is adjust your brain’s internal resolution engine. The advantage (and simultaneously the disadvantage) of reusing . is that it adds uniformity, now everything can be called with UFCS (Uniform Function Call Syntax) and everything can be called with (Uniform Method Call Syntax). As a bonus, we can also get disambiguation with paths in method call syntax.
Personally, I don’t have a strong preference either way. But maybe having a different syntax has a better chance of getting accepted? The “|>” operator also has a potential advantage that it could potentially work for any free function or macro, whether the original author marked it for such use or not, which could also be an advantage (it works for legacy functions and macros) and disadvantage (it works for things that it doesn’t make sense for).