[swift-evolution] two protocols with the same method name

[Thorsten Seitz]

Nice!

-Thorsten 

> Am 14.01.2016 um 00:48 schrieb Joe Groff via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> On Jan 7, 2016, at 2:18 AM, Grzegorz Leszek via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I suggest compile warning if one classes/structs/enums implements
>> protocols with the same name.
>> It could lead to confusions, when methods of those protocols will mean
>> different things.
>> It will force to implement parent protocol with shared methods or
>> change method in one of the protocols.
>> Below is an example.
>> Regards,
>> Greg
>> 
>> //💍
>> protocol A {
>> var ring: String { get }
>> }
>> 
>> //🔔
>> protocol B {
>> var ring: String { get set }
>> }
>> 
>> class X: A, B {
>> var ring: String {
>>   get {
>>     return "💍"
>>   }
>>   set {
>>     self.ring = newValue
>>   }
>> }
>> }
>> let x = X()
>> let somewhereInTheProject = "\(x.ring) the bell"
>> x.ring = "🔔" // ERROR!
> 
> Swift's protocol conformance model doesn't rely on the name of the member matching the name of the requirement it satisfies. One possibility here is to introduce an attribute to explicitly declare what protocol requirement(s) a member is intended to satisfy:
> 
> class X: A, B {
>  @implements(A.ring)
>  var weddingRing: String
> 
>  @implements(B.ring)
>  var ringtone: String
> }
> 
> As other noted, protocols with same-named requirements but different semantics are rare in practice, and it's occasionally useful to intentionally overlap requirements (I believe the CollectionType hierarchy does this in places), so the current behavior feels like a reasonable default to me. I can see value in requiring it to be explicit though.
> 
> -Joe
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution