[swift-evolution] Operator implementation inside struct/class body
Haravikk
e-mail at haravikk.me
Sun Jan 31 07:14:54 CST 2016
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? 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.
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.
> On 31 Jan 2016, at 05:26, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>
>>
>> On Jan 30, 2016, at 9:03 PM, Vanderlei Martinelli via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> Since the first public betas I’d like to know why operator implementation have to be written outside the body of its owner.
>
> Yep, this is a generally desirable feature (at least for symmetric operators). This would also be great to get dynamic dispatch of operators within class declarations. I don’t think we have a firm proposal nailing down how name lookup works with this though.
>
> -Chris
>
>>
>> Take as example the code:
>>
>> protocol MyEquatable {
>> @warn_unused_result
>> func ==(lhs: Self, rhs: Self) -> Bool
>> }
>>
>> struct MyStruct: MyEquatable {
>> let foo: String
>> let bar: String
>> }
>>
>> func ==(lhs: MyStruct, rhs: MyStruct) -> Bool {
>> return lhs.foo == rhs.foo && lhs.bar == rhs.bar
>> }
>>
>> Why we cannot write:
>>
>> protocol MyEquatable {
>> @warn_unused_result
>> func ==(lhs: Self, rhs: Self) -> Bool
>> }
>>
>> struct MyStruct: MyEquatable {
>> let foo: String
>> let bar: String
>>
>> func ==(lhs: MyStruct, rhs: MyStruct) -> Bool {
>> return lhs.foo == rhs.foo && lhs.bar == rhs.bar
>> }
>>
>> }
>>
>> Any thoughts?
>>
>>
>> -Van
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160131/e22fdb11/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2475 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160131/e22fdb11/attachment.p7s>
More information about the swift-evolution
mailing list