[swift-evolution] Operator implementation inside struct/class body

Chris Lattner clattner at apple.com
Sun Jan 31 22:55:31 CST 2016

> On Jan 31, 2016, at 5:14 AM, Haravikk <e-mail at haravikk.me> wrote:
> Definitely a +1 from me for the feature.
> What are the name lookup issues? Do you mean cases where an operator for Foo == Foo exists in more than one location?

Yes.  Name lookup has to have a well defined search order, which defines shadowing and invalid multiple definition rules.

> Personally I’d just stick with what we have now, i.e- treat operator implementations within a specific class/struct as being globally defined anyway and throw an error if the same signature is declared more than once.

We need multiple modules to be able to define instances of an operator, we need operators in extensions, and we need retroactive conformance to work, as with any other member.

> One minor issue around putting them in class/struct bodies though is that I wonder if perhaps a keyword other than func should be used? While they are functions, they aren’t methods of instances. At the very least they should probably need to be static.

As we do with protocols, I think we should continue to treat “func <operatoridentifier>” specially.  That said, I’d welcome other people’s thoughts on this.  Would it be more clear to have:

protocol P {
  operator ==(a : Self, b : Self) -> Bool

Does “operator” buy us anything there over func?  If we went this direction, it would require taking operator as a keyword.


More information about the swift-evolution mailing list