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

[Andrew Bennett]

I like this approach, @implements is nice, clear, concise and handles many
cases.

It will require your proposal, or similar, to be universally applicable
though, but I expect it will pass: Naming Functions with Argument Labels.

Many Cocoa delegate protocols will have similar function names, ie.
collectionView(...).

On Thursday, 14 January 2016, Joe Groff via swift-evolution <
swift-evolution at swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:

>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/0504e413/attachment.html>