It took another good night’s sleep to be able to realise what I really wanted 
to express yesterday. It comes down to three points:

1) Protocol marking is not really a proposal, but a bug report.
2) I do not think it needs new syntax
3) There is probably a lot of code out there that “uses” this bug. Cause us to 
think that this is a source breaking change. It is not, but that existing code 
is “wrong” and needs to be redesigned.

I am not sure this covers all the cases discussed in this thread, I simply do 
not have to time to follow all discussions in full detail.

> > -- module A --
> > class A {
> >   func foo() {}
> > }
> >
> > -- module B --
> > protocol Foo {
> >   func foo()
> > }
> > extension A: Foo {}


let C = A()


I’d say that you have two functions here:
A.foo() and A.Foo.foo()

To call the first, write C.foo()
To call the second, write (C as! Foo).foo()

No ambiguity.

Note that A.foo() was never intended to be used as an implementation for 
protocol Foo, thus why should you be able to see it as such? That imo is a bug 
in the language. Its not flexibility, it’s dangerous.

Rien.


> On 22 Sep 2016, at 18:27, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 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@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@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@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to