[swift-evolution] Mark protocol methods with their protocol

[Xiaodi Wu]

Extensions in Swift aren't a first-class entity; they have no name and no
representation in the type system. If an extension to A does something,
then A does something. If A conforms to P, then A.foo is the implementation
of P.foo.
On Thu, Sep 22, 2016 at 11:06 Marinus van der Lugt via swift-evolution <
swift-evolution at swift.org> wrote:

> That does not seem right to me. A does not implement any protocol.
> The extension of A implements a protocol thus foo() should not be seen as
> part of the protocol at all.
>
> So far, I have always extended a class when adding protocol compliance.
> I.e. it is always clear
>
> I.e.
>
> protocol P {
> func foo()
> }
>
> class A {
>  fun foo() {} // Should not be regarded as implementation of P
> }
>
> extension A: P {
>  func foo() {} // This is the implementation of P
> }
>
> >
> > On 22 Sep 2016, at 11:28, Martin Waitz via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Hi,
> >
> > isn't it perfectly fine to conform to multiple unrelated protocols which
> both require the same member?
> > Or to declare protocol conformance in some unrelated module?
> >
> > Am 2016-09-22 07:15, schrieb Karl via swift-evolution:
> >> I would like to make it a requirement if not inside a protocol
> >> extension which declares a conformance, and actually build the
> >> protocol name in to the member in an ABI-breaking way.
> >
> > IMO, this is much too restrictive.
> > When we force the protocol name into the member, we make it impossible
> to conform to multiple protocols.
> > Well ok, we could create alias names for all protocols.
> > But often you don't know which protocols to conform to when you compile
> your module!
> >
> > What about:
> >
> > -- module A --
> > class A {
> >   func foo() {}
> > }
> >
> > -- module B --
> > protocol Foo {
> >   func foo()
> > }
> > extension A: Foo {}
> >
> > What is your ABI name for A.foo()?
> >
> > Let's keep it simple!
> > If a simple warning about unrelated methods in a protocol conformance
> extension solves 95% of our problem,
> > then we shouldn't overengineer and throw away all our flexibility just
> to be 100% explicit about which protocol uses which members.
> >
> > --
> > Martin
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20160922/5ea36418/attachment.html>