I've been mulling over my [RFC on a replacement for `dotOperator`](https://github.com/nim-lang/RFCs/issues/372). I wrote that RFC because this [RFC on modifying dot-like operator precedence (#341)](https://github.com/nim-lang/RFCs/issues/341) was labelled "let's see what breaks accepted", and I really wanted to get to a better solution. I'm still looking for a better solution, so I'm looking for feedback on this idea:
What if operator precedence was overridable? I know it sounds like a terrible one given how flexible Nim already is, but hear me out! I read somewhere in the forums that someone once suggested to add overridable operator precedence to the compiler, and it seemed that Araq had flat out refused. I think there are several good reasons to not allow this, the most important for me being: it's hard to understand code that looks exactly the same but behaves differently. But could the advantages of this feature outweigh its disadvantages if it were limited somehow? What do you guys think about this feature, but with the following limitations: 1. "Built-in operators" cannot have their precedence overridden. 2. "Custom operators" with precedence overrides must be declared in the same module as the type they operate on (idea stolen from comment on my RFC). 3. "Custom operators" that don't have their precedence overridden will retain the old precedence rules. I guess "built-in operators" would have to be defined for limitation #1. Built-in operators could be the ones for basic types, like `.`, `+`, `-`, etc (maybe a list similar to [Dlang's](https://dlang.org/spec/operatoroverloading.html)?). Essentially, this is a superset of the solution suggested in [RFC 341](https://github.com/nim-lang/RFCs/issues/341). It gives more control over the behavior of operators, and doesn't introduce special casing. At the same time, it is (probably) not as radical as my RFC, and could be a safer addition. The only language I've used that has this feature is [Swift](https://docs.swift.org/swift-book/ReferenceManual/Declarations.html#ID380), and people use it there for some weird-looking operators. I also noticed that [Dlang](https://dlang.org/spec/operatoroverloading.html) _doesn 't_ have this feature, but that language limits the operators that can be overloaded (whereas Nim limits the _characters_ that can be in an operator), so it makes sense not to have this feature there. I think Nim sits quite snugly in between those two languages in terms of operators, so maybe this feature could be an addition that makes sense? As for the syntax, that could simply be in the form of a special pragma attached to the operator being defined.
