@infix to unlock operator notation is, in fact, controversial!

[odersky]

@Ichoran

@infix encourages regularity in how a single library is used, but discourages regularity in code that consumes libraries, as there is no mechanism to force different library authors to make the same decision about which methods are infix. If, for instance, one library makes contains infix and another doesn’t, you cannot adopt a consistent-with-the-library usage for contains . Therefore, the effect of @infix will not be, as it claims, to increase regularity, but actually to just decrease the usage of infix notation–it will always be bad practice to use something infix, even if it’s notated @infix , because you never know when some other library will fail to use the annotation, and your code will be internally inconsistent in style.

To give some feedback on this argument: I don’t think that will be a problem, at least not in the long run. There will be strong normative forces at work here. If a library deviates from the others in its choice of infix, but still defines common method names like map that are also defined elsewhere, users will not like the experience and stop using the library. In the end I believe the consensus will be predominantly dot syntax, which is fine by me.

There will be some exceptions, of course, e.g. by, to, until, eq, ne, min, max in the std lib. There will be others in DSLs and libraries, in particular to express infix operators.