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 
> <swift-evolution@swift.org> wrote:
> 
>> On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution 
>> <swift-evolution@swift.org> 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
> 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