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

The SIP meeting notes (which, incidentally, are excellent!–I’m impressed by how many issues were discussed in that meeting, and appreciate how clear the write-up is!) from 2020-03-11 make this claim: "@infix is uncontroversial".

Please note this discussion, which was full of controversy: The @infix Annotation

In particular, the primary argument in favor of @infix is to increase regularity, but a case has been made that it will actually decrease regularity. There has been no clear argument that the original view is in fact correct!

It would be nice, if @infix is going in, to have at least an official acknowledgement of the arguments against it. Better would be to make counterarguments, and argue against alternative proposals that claim they would better accomplish the same stated goal. (The people who argued in favor of @infix did not, as far as I could tell, adequately address the criticisms.)

To summarize the long thread, the most weighty criticism to my eyes is the following:

@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.

It would be nice to have a clear, reasonable comprehensive, and decently compelling argument in favor of @infix somewhere. Or, if deeper reflection suggests that the arguments against have sufficient merit, maybe the decision should be revisited.

It certainly shouldn’t just be classified as “oh, uncontroversial, so let’s do it”. If “uncontroversial” means only, “the people at this committee meeting all agree”, it’s kind of a shame that the people who believe this is a bad idea don’t have their position represented on the committee.


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.

1 Like

For alphanumeric method names, I see such a decrease, ecosystem-wide, as highly desirable.

I am doubtful that there is such wide diversity of choice in libraries that people can stop using one simply because it messes up their infix syntax. With JSON parsers, okay, probably so.

But perhaps combined with peer pressure it will happen. Also, requiring @infix to match with inheritance provides further pressure to conform–otherwise you run into cases where it is impossible to implement two traits with the same method signature.

Maybe this will do the trick. Maybe it’ll be all over the place. I can’t predict, personally.

It would be nice if the documentation was upfront with this. It seems to be rather coy about that as an expected outcome.

The documentation says in justification, only

The purpose of the @infix annotation is to achieve consistency across a code base in how a method or type is applied. The idea is that the author of a method decides whether that method should be applied as an infix operator or in a regular application. Use sites then implement that decision consistently.

But you are not anticipating that this model (where the author decides) is the whole story, because the situation will strongly encourage the author to adopt the consensus. Someone else will already have decided for them, and they’d better go along or face the wrath of the community.

Furthermore, it’s also not accurate that “use sites then implement that decision consistently”. @infix does not allow the author to require infix notation! It only enables the option, which means that the author is free to decide whether they want the consistency of dot notation, or the inconsistency of whatever.

And, on top of that, the user has to remember whether it’s @infix or not. When it’s so much simpler to just assume “not”, why use infix except in vanishingly rare cases, even if the library author intended for you to?

The motivation section should be rewritten to give a realistic accounting of the actual achievable goals (or should admit that although this was the original motivation, it’s recognized that the goal will not be achieved as stated). The motivation is, or at least the consequence will be whether so motivated or not, to dramatically reduce the usage of operator notation, while providing authors the ability to retain it for the most critical operations.

I strongly disagree that reducing the ability to use operator notation is beneficial. As I’ve stated before, I think formatters and linters as part of the default toolchain are vastly superior, both because they can enforce consistency across libraries, and because they enable all sorts of other wonderful benefits for users. Furthermore, I’ve been programming for over thirty years now, with languages ranging from Modula-2 to Rust with a lot of other things in between, so I can without any hesitation say that losing operator notation is going to significantly (but not critically) negatively affect the readability of my code. I miss it all the time when I’m coding in Rust or C++.

But, hey, you win some, you lose some when it comes to language features. Not everyone feels the same way. I get that.

What I don’t understand is not using the actual motivations for motivation, and not advocating for the likely consequences (leaving people to discover it on their own).

I also don’t understand the characterization of the change as non-controversial, when there was quite a bit of negative feedback.

Both these things can be pretty easily fixed, however, if the resolve is to continue with @infix.


The intent of that wording was to characterize the proposal’s status among committee members whose opinion we know, not more widely than that.

I’ve submitted a pull request revising the wording in the minutes as follows:

-`@infix` is uncontroversial, ...
+No one in the committee who has registered an opinion is against `@infix`, ...

It’s a bit complicated because in the “straw poll” we did before the retreat, the @infix and @alpha proposals were treated together. We’ve now separated them from each other, but we don’t yet know how all of the committee members are feeling about them separately.


I think we have to agree to disagree here.

@SethTisue - Great, thanks! I think it’s important to be clear about that, given that committee support isn’t necessarily reflective of community support.

FYI, I think @alpha is great.

Sure. Not all preferences are universal. However, it’s a lot easier to agree to disagree when (1) it’s acknowledged that there’s disagreement, and (2) the latest intent and best understanding of consequences are used to express the motivation.

This was not measuring up on either count, though it sounds like Seth is going to fix (1), so :+1: to that at least.