Infix call syntax for binary functions #8824

bluss opened this Issue Aug 28, 2013 · 8 comments


None yet

5 participants

bluss commented Aug 28, 2013

Allow calling binary functions infix. Functions and method calls are enclosed by mandatory parantheses, and these obscure the logic of the code when nested.

Methods are already placed neatly (like operators) bewteen two objects (a .eq (b)) but with an infix call we can make this easier to read.


can be

a `and` b `and` c `and` d

and instead of overloading + for lists we can have

~[1,2,3] `concat` ~[2,3,4]

or a parser can use

AlNum `and` (AlNum `or` Hyphen)

Infix binary functions are simpler and have less drawbacks compared to arbitrary user operators. They are also more flexible than the builtin set of operators (that are limited in number and force call by &T).


For future reference we had some discussion about this on reddit: [link]

The most important point was that backticks are probably not desirable, and a better syntax might be:

a \and b \and c \and d
~[1,2,3] \concat ~[2,3,4]
AlNum \and (AlNum \or Hyphen)

would this have a way of setting fixity / associativity?


Well this whole thing is speculative, so all we have is our ideas and opinions. I think that would introduce usability issues again -- if you're looking at some code using \operators, you wouldn't know how to read it until you looked up all of the relevant fixity and associativity declarations. @cartazio what's a use case where you would want it?


numerical linear algebra code. Probably where I'd be building up an AST model of the "math" then running a version that internally does an inplace update execution using a fixed number of pre allocated array buffers.


Would having to explicitly parenthesize be horrible?


nope, was just asking. I understand that being conservative for near term features is important.


@brson Any thoughts on this? I'm guessing this would require a proper RFC with the new process, but is this something Rust would be interested in supporting?


Closing, a change such as this should go through the RFC process, both to flesh out and get community feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment