> 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
