I think the infix warnings is a reasonable improvement to the old Scala2 style of letting each callsite decide how it wants to call a method, for almost everybody:
-
For those who do not use infix methods much, it encourages a default style where each method has to be infix or not.
-
For those who do use additional methods infix, it forces them to list out those methods in their build file, and enforces that only the methods they intend to be infix can be used as infix methods. Most people have a subset of methods they expect to use as infix, and this forces you to be up front about it
Strategically, I think this is the right direction to go in. You get coarse grained flexibility at the definition-site or project level, rather than fine-grained flexibility per-callsite. This helps projects and the ecosystem as a whole become more uniform while still preserving the flexibility to use infix methods where necessary.
And the reason it’s a warning rather than an error is intentional: warnings are silenceable and meant to be silenced if necessary! So we should not feel bad about silencing warnings that are false positives, or do not apply to specific blocks, files, or projects. The warning is a gentle nudge in a particular direction that is generally broadly applicable, but one that the project owner can decide otherwise if they so choose