[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