[swift-evolution] Mark protocol methods with their protocol

[Rien]

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 at 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 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution