I think the central question w.r.t special operators is: How far do we want to go in Rust in supporting embedded domain specific languages (eDSLs)?
The reason this is important is that all special operators, from
++ are in fact all domain specific operators. It’s just that most people happen to be intuitively familiar with the domain of basic integer/decimal arithmetic, thus they can readily understand that.
Those same people likely have no exposure to symbols from other domains, and thus find them relatively unreadable. If they used them daily for a while it would become second nature soon enough, but they don’t, so it doesn’t.
Therefore my argument is that Special Syntax for Domain-Specific Operators should be viewed as a primitive to construct
eDSLs with, and nothing else. And even then it should be viewed with suspicion: syntax soup code (think perl, brainfuck, SBT’s configuration etc) burdens the user with a steeper learning curve than regular names.
As a bit of a tangent, rust’s
macro_rules! facility is a strikingly poor tool to create
eDSLs with, which leaves boilerplate-cutting as the primary (not unimportant!) use case. I haven’t mucked around with procedural macros yet enough to know for sure, but I expect those to be powerful enough to express any random
eDSL that uses token sequences supported by the Rust parser. Relative to
macro_rules! this comes at the cost of imperative rather than declarative code, rejection of the stable Rust compiler, and additional complexity.