> 4. What do you think about adding a rule to disallow defining member > operators that don't satisfy a protocol requirement? > > Dmitri
I’m wondering if we could go in the opposite direction, instead. If I’m understanding the proposal correctly, it only boils down to relaxing the rules about naming of (static) methods: the other functionality needed to implement operators this way is already there. What we are missing is that we currently have to use normal words to name the methods, because the Swift grammar reserves certain character to only be used by operators. If I understood the rationale correctly, this limitation was a technical requirement to ensure the compiler doesn’t have to deal with ambiguous syntax. It seems to me that if this proposal is taken to its logical conclusion, by completely forbidding operator declarations anywhere but at global scope, the source of the ambiguities should be removed, which should allow more freedom on method names. To be clear, the rules would remain the same for global functions, but would become more relaxed for methods. If we allowed this, it would be possible to revisit another proposal which was floated by some time ago to improve the names of functional vs. mutating methods. It would become possible to simply do e.g. instead of func union(other: Self) -> Self mutating func formUnion(other: Self) we could simply to func union(other: Self) -> Self mutating func =union(other: Self) and then x = y.union(z) y.=union(z) — Nicola _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
