<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div></div><div style="direction: inherit;">I'd also say that one or two keywords are superior than the protocol naming approach in terms of implementation simplicity (for the core team).</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">My suggestions:</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Either "conform" or "implement" should be a required keyword for all properties/functions which implement a protocol (also in protocol extensions)</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">"override" should be used if a default implementation or a member of a superclass is overridden.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">If you are overriding a default implementation of a protocol <span style="background-color: rgba(255, 255, 255, 0);">"conform" / "implement" is also required.</span></div><div style="direction: inherit;"><br></div><div style="direction: inherit;"><div style="direction: inherit;"><span style="background-color: rgba(255, 255, 255, 0);">// Retroactive conformance (old behavior) but only in extensions</span></div><div style="direction: inherit;"><span style="background-color: rgba(255, 255, 255, 0);">extension Foo: @retroactive Baz {</span></div><div style="direction: inherit;"><span style="background-color: rgba(255, 255, 255, 0);"> // only some members of Baz are implemented here (they need the keywords)</span></div><div style="direction: inherit;"><span style="background-color: rgba(255, 255, 255, 0);"> // the other members outside the extension don't need any additional keywords</span></div><div style="direction: inherit;"><span style="background-color: rgba(255, 255, 255, 0);"> // note: you can use "@retroactive" and "conform" in conjunction</span></div><div style="direction: inherit;"><span style="background-color: rgba(255, 255, 255, 0);">}</span></div></div><div style="direction: inherit;"><br></div><div style="direction: inherit;"><br></div><div style="direction: inherit;"><b>Future directions:</b></div><div style="direction: inherit;">"conform(ProtocolName)" / "override(ProtocolName)" can be used to disambiguate.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">// reducing boilerplate</div><div style="direction: inherit;">extension Foo: conform Bar {</div><div style="direction: inherit;"> // These declarations can only implement Bar and don't need the "conform" keyword</div><div style="direction: inherit;">}</div><div style="direction: inherit;"><br></div><div style="direction: inherit;"><b>Final question:</b></div><div style="direction: inherit;">Should we also require a marker for implemented protocol members in the interface?:</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">protocol Foo {</div><div style="direction: inherit;"> defaulted func foo()</div><div style="direction: inherit;">}</div><div style="direction: inherit;">extension Foo {</div><div style="direction: inherit;"> implement func foo()</div><div style="direction: inherit;">}</div><div style="direction: inherit;"><br></div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Best regards</div><div style="direction: inherit;">Maximilian</div><div><br>Am 22.09.2016 um 16:44 schrieb Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><span>On 22.09.2016 11:10, Jean-Denis Muys via swift-evolution wrote:</span><br><blockquote type="cite"><span>I watched this thread with a lot of attention, starting neutral. You</span><br></blockquote><blockquote type="cite"><span>must say that Karl won me over. His proposal would make Swift more</span><br></blockquote><blockquote type="cite"><span>expressive, and less error prone in cases of protocol conformance with</span><br></blockquote><blockquote type="cite"><span>name collisions. I am at this point +1</span><br></blockquote><span></span><br><span>Actually I also support Karl's suggestion in general. It is trying to solve IMO important problems and make Swift's protocol programming safer and less fragile. Also it adds new interested features for working with protocols.</span><br><span></span><br><span>But in reality, I don't feel like his suggestion could be accepted by core team and community and even if it could be supported, it seems for me that *implementation* of his proposal requires a huge amount of time and big changes in how Swift is working currently. (Probably some one who knows Swift internals could comment regarding this)</span><br><span>So, theoretically we'd have these improvements not in near future and I think the problem discussed is very important to be addressed in Swift as soon as possible.</span><br><span>I base my opinion also on previous discussions regarding similar subjects.</span><br><span></span><br><span>My suggestion regarding a marker for protocol implementation method/prop in type - solves most of the addressed problems with protocol conformance and with fragile of such conformance, and adds one new keyword (or even zero - right now I think the `override` is better choice for such "marker"). I believe this proposal could be implemented with much less amount of work and with less changes to current internals of Swift and to current code base, and so we can have such a big improvement in Swift soon. So my intention was to suggest solution that can dramatically improve Swift's protocol programming with "small" amount of changes for compiler(internals) and for existed sources.</span><br><span></span><br><span>But it seems like the direction chosen by the core team and supported by many in community - is just a warning if extension conforming type to protocol contains unrelated to that protocol methods/props. I see that this solution can improve protocol programming in some areas, but does not address some IMO important issues we discussed in the thread :</span><br><span></span><br><span>* Currently extension can not have stored properties. So, if we want to implement protocol's props as stored properties - we can't move them to extension. So to implement this soulution - we need stored properties in extensions. It is not clear if and when they are expected.</span><br><span></span><br><span>* This solution will not require the safety(regarding protocol conformance) from a developer, it will only inform and only if protocol conformance defined in extension. So, when you use 3rd party source code - your project will not be protected for the discussed problems.</span><br><span></span><br><span>* To write safe code I can't group methods/props as I want, I have to declare a number of extensions per-protocol (in case my type conforms to a number of protocols)</span><br><span></span><br><span>* This solution does not solve problem of near-miss signature of method definition in protocol extension like here:</span><br><span>protocol A { func foo() }</span><br><span>protocol B : A {}</span><br><span>extension A { func foo() }</span><br><span>extension B { func voo() } // typo. how to "mark" this should be impl?</span><br><span>"my" suggestion:</span><br><span>extension A { override func foo() }</span><br><span>extension B { override func foo() }</span><br><span></span><br><span>* Not clear how to write safe code with that approach if we implement protocol requirement in derived class, but conformance was declared in base (but not implemented) :</span><br><span>protocol P { func foo() }</span><br><span>extension P { func foo() }</span><br><span>class A : P {}</span><br><span>class B { func foo() } // we can't move this to extension, B already conforms to P</span><br><span>, and in opposite to "my" `override` requirement for implementation, if `A` will add its own foo() implementation - we'll have to change B's definition(need to add `override` for B.foo )</span><br><span>"my" suggestion:</span><br><span>class B { override func foo() }</span><br><span></span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Jean-Denis</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Sent from my iPhone</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 22 Sep 2016, at 07:15, Karl via swift-evolution</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I would like to make it a requirement if not inside a protocol</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>extension which declares a conformance, and actually build the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>protocol name in to the member in an ABI-breaking way. We could make</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>it additive by generating forwarding thunks from the old symbols to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the new ones, but it would be better if we could just solve the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>overlapping-members problem before then.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>That would mean you never get collisions between protocol members.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>There’s loads of amazing stuff we can do with that ability, and ways</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>we can extend it to reduce a lot of boilerplate that occurs when you</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>want to have multiple representations of the same data (String is just</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>an example).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I don’t really care about the syntax we need to make it liveable. We</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>could automatically insert the protocol names for unambiguous members</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>at call-site, or something else.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This thread was originally about making the *syntax* a requirement; I</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>agree with that, and I would actually take it one (or several) steps</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>further, solving other problems along the way.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On 22 Sep 2016, at 06:46, Russ Bishop <<a href="mailto:xenadu@gmail.com">xenadu@gmail.com</a>> wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>on Tue Sep 20 2016, Karl <<a href="http://razielim-AT-gmail.com">razielim-AT-gmail.com</a>> wrote:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I think the best way is to prefix the member name with the</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>protocol, e.g:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>protocol MyProto { var aVariable : Int func aFunction() } class</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>MyClass : MyProto { var MyProto.aVariable : Int func</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>MyProto.aFunction() { … } }</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>...</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>CC-ing Dave A, to understand better if this fits with the vision</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>of protocols</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I generally agree with Doug. The canonical way to indicate “this</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>method/property/type implements a requirement of protocol P”</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>should be to define the entity in an extension that also adds</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>conformance to P. If that's inadequate indication in some way we</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>should find a way to enhance it. I wouldn't mind the notation</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>above, but only as a fallback, not a reuquirement.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>-- -Dave _______________________________________________</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Indeed this is exactly how C# handles Interfaces (protocols). The</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>default is the exact same way Swift works - by matching names. If</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>there is a collision you specify Protocol.memberName. Its simple and</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>in the years I was writing C# code it was flexible enough to cover</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>most reasonable scenarios, without adding a bunch of boilerplate.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Russ</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________ swift-evolution</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>mailing list <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><span>_______________________________________________ swift-evolution mailing</span><br></blockquote><blockquote type="cite"><span>list <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>