<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div>Am 23.09.2016 um 12:47 schrieb Vladimir.S &lt;<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>&gt;:<br><br></div><blockquote type="cite"><div><span>On 23.09.2016 11:05, Maximilian Hünenberger wrote:</span><br><blockquote type="cite"><span>I'd also say that one or two keywords are superior than the protocol naming</span><br></blockquote><blockquote type="cite"><span>approach in terms of implementation simplicity (for the core team).</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>My suggestions:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Either "conform" or "implement" should be a required keyword for all</span><br></blockquote><blockquote type="cite"><span>properties/functions which implement a protocol (also in protocol extensions)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><blockquote type="cite"><span>"override" should be used if a default implementation or a member of a</span><br></blockquote><blockquote type="cite"><span>superclass is overridden.</span><br></blockquote><span></span><br><span>Maximilian, again, you *do not know* if the conformed protocol, that has no default implementations *at the moment of your code writing* will or will not have default implementations at the *moment of compilation*.</span><br><span>Consider this scenario:</span><br><span></span><br><span>Step 1. You got 3rd party source file for your project, and you don't want/have no rights to change it, probably it is shared source used also in other projects, that code contains:</span><br><span></span><br><span>protocol A { func foo() }</span><br><span></span><br><span>class B : A {</span><br><span> &nbsp; &nbsp;conform func foo() {...}</span><br><span>}</span><br><span></span><br><span>all is OK with this code, no default implementation, B.foo marked with `conform`.</span><br><span></span><br><span>Step 2. In your project in some of your files you decided to add default implementation of protocol A:</span><br><span></span><br><span>extension A {</span><br><span> &nbsp; &nbsp;implement func foo() {...}</span><br><span>}</span><br><span></span><br><span>Now, your project will not compile - B.foo() must me marked with 'override' as protocol `A` has default implementation of foo().</span><br><span>If you change `conform` to `override` in 3rd party source file, it will not compile in some other project where no default implementation defined for `A` protocol.</span><br><span></span><br><span>That is *why* I believe the `override` as requirement as marker for protocol implementation method/prop is the best solution. See, in case `override` will be required, the initial source file will be like this:</span><br><span></span><br><span>protocol A { func foo() }</span><br><span></span><br><span>class B : A {</span><br><span> &nbsp; &nbsp;override func foo() {...} // implementation</span><br><span>}</span><br><span></span><br><span>and it will compile ok : if A has default implementation and if A has no default implementation.</span><br><span></span><br><span>So, after you added default implementation in your project - no changes should be made to that 3rd party source file.</span><br><span></span><br><span></span><br></div></blockquote><div><br></div><div>In case of my suggestion this is an easy fix: `override` is not required if it overrides a member of an extension in another module.</div><div><br></div><div>My basic idea is to distinguish between implementation and (true) overriding (of other members. Do you agree?</div><div><br></div><div>Consider this:</div><div><br></div><div>protocol A1 {</div><div>&nbsp; &nbsp; func foo()</div><div>}</div><div><br></div><div>extension A1 {</div><div>&nbsp; &nbsp; implement func foo() {}</div><div>}</div><div><br></div><div>protocol A2: A1 {</div><div>&nbsp; &nbsp; override func foo() {}</div><div>}</div><div><br></div><div>In this case you <b>know</b> that `foo` in extension A1 does not override any other method.</div><div><br></div><div>Best regards</div><div>Maximilian</div><br><blockquote type="cite"><div><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If you are overriding a default implementation of a protocol "conform" /</span><br></blockquote><blockquote type="cite"><span>"implement" is also required.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>// Retroactive conformance (old behavior) but only in extensions</span><br></blockquote><blockquote type="cite"><span>extension Foo: @retroactive Baz {</span><br></blockquote><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;// only some members of Baz are implemented here (they need the keywords)</span><br></blockquote><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;// the other members outside the extension don't need any additional</span><br></blockquote><blockquote type="cite"><span>keywords</span><br></blockquote><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;// note: you can use "@retroactive" and "conform" in conjunction</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>*Future directions:*</span><br></blockquote><blockquote type="cite"><span>"conform(ProtocolName)" / "override(ProtocolName)" can be used to disambiguate.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>// reducing boilerplate</span><br></blockquote><blockquote type="cite"><span>extension Foo: conform Bar {</span><br></blockquote><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;// These declarations can only implement Bar and don't need the</span><br></blockquote><blockquote type="cite"><span>"conform" keyword</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>*Final question:*</span><br></blockquote><blockquote type="cite"><span>Should we also require a marker for implemented protocol members in the</span><br></blockquote><blockquote type="cite"><span>interface?:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>protocol Foo {</span><br></blockquote><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;defaulted func foo()</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span>extension Foo {</span><br></blockquote><blockquote type="cite"><span> &nbsp;&nbsp;&nbsp;implement func foo()</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Best regards</span><br></blockquote><blockquote type="cite"><span>Maximilian</span></blockquote></div></blockquote><br></body></html>