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

Goffredo Marocchi panajev at gmail.com
Mon Feb 1 01:38:00 CST 2016


Comments inline.

Sent from my iPhone

> On 1 Feb 2016, at 04:55, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> 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.
> 

If it can help bring the feature in more painlessly then I think it is a worthy sacrifice in terms of reserving it as a keyword. It is not uncommon to see operator overloading taken as a special case anyways.


> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


More information about the swift-evolution mailing list