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