If Swift 4 will make it impossible to tackle this again, I do not think discussing this can be avoided for Swift 3.1... I am afraid we are rushing into Swift 4 a bit too quickly, but perhaps it is just silly old me :).
Sent from my iPhone > On 19 Sep 2016, at 19:18, Charles Srstka via swift-evolution > <[email protected]> wrote: > >> On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution >> <[email protected]> wrote: >> >>> On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote: >>> >>> Let me give a concrete example of how retroactively modeling is used. >> >> Karl is suggesting interesting but complex and IMO too much code-breaking >> idea that I don't believe can be implemented at all in a reasonable amount >> of time to be a part of Swift as soon as possible, to address the discussed >> issue with protocols. >> >> I wonder what objections could be made on the solution proposed below, which >> should solve a major(IMO) number of issues with protocol conformance and >> introduce only 1 keyword. Such solution will make Swift better as >> Protocol-Oriented language and later we can even improve it, but it can >> already solve a big number of issues: >> >> 1. As soon as possible we add 'implement' keyword which is required to mark >> method/property that was defined in type or extension exactly to conform to >> some protocol. >> >> 2. The 'implement' required only at a moment of 'direct' conformance, i.e. >> when you declare methods/props of the type/extension that explicitly >> conformed to protocol. >> >> 3. Retrospective conformance will not require this keyword and will work for >> now just like it is working today. >> >> 4. Later, if this will be possible at all, we can extend this model to >> support separate implementation of protocols with same requirements in the >> same type, explicit protocol name in implemented methods/props and >> improvements for retrospective conformance. For example some variants for >> *future* improvements: >> >> 4.1 Different implementation for different protocols >> class Foo : ProtocolA, ProtocolB { >> implement(ProtocolA) func foo() {...} >> implement(ProtocolB) func foo() {...} >> } >> class Foo : ProtocolA, ProtocolB { >> implement ProtocolA { >> func foo() {...} >> } >> implement ProtocolB { >> func foo() {...} >> } >> } >> etc >> >> 4.2 Retrospective conformance: What is the main problem with retrospective >> conformance? As I see it now(correct me, if I missing something), the >> problem arises in such situation: >> * we *expect* that some method(s) in type will play the role of >> implementation of protocol's requirements, so we retrospectively conform >> that type to the protocol. >> * but protocol has default implementation for its requirements >> * and type's methods, that we *expect* to play roles for protocol >> implementation, has different parameters or slightly different method name >> at all. >> >> I.e. when we have this set of code logic: >> >> type T { >> func foo() >> } >> >> protocol P { >> func foo(x: Int) >> } >> >> extension P { >> func foo(x: Int) {...} >> } >> >> extension T : P { // expect foo in T will play role of P.foo >> } >> >> I support the opinion that it is not an option to require to explicitly list >> conformed methods/props in type extension for retrospective conformance. >> But I do believe we need a way to *express our intention* regarding the >> retrospective conformance: do we expect that type already contains >> implementation for some protocol's requirements OR we are aware that >> protocol can have defaults for some methods and our type does not contains >> some implementations. >> >> So, the solution here IMO is some syntax to express that intention. Right >> now I think that we can use current syntax "extension T : P" to keep it >> working as it now works: "I'm aware of all the names, defaults etc. Treat >> this as usually you did". But for example something like "extension T: >> implement P {..}" or "extension T: P(implement *) {..}" will say that we >> *expect* that all requirements of P protocol should be implemented inside T >> type. Or some syntax inside extension to specify the list of methods/props >> we expect to be implemented in T. Or "extension T : P(implement foo, >> bar(x:y:)) {..}".. Should be discussed. >> >> But again, IMO this could be discussed later, after we'll have 'implement' >> for most important place - in type definition for method/prop that we >> created exactly for the conformed protocol. > > I would be completely +1 on this. > > Charles > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
