<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 22, 2016 at 7:02 PM, Charles Srstka <span dir="ltr">&lt;<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Aug 22, 2016, at 6:33 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; That&#39;s a good point. Since you&#39;re proposing an optional keyword, though, aren&#39;t you describing a linter functionality?<br>
<br>
</span>If the optionality of the keyword bothers you, there are multiple ways to do it:<br>
<br>
Solution #1: Optional keyword.<br>
<br>
protocol P {<br>
        func giveUpTheFunc()<br>
}<br>
<br>
struct S: P {<br>
        implement func giveUpTheFunc()<br>
}<br>
<br>
Solution #2: Required keyword, but with a manual override for protocols that need to be retroactive.<br>
<br>
protocol P {<br>
        @retro func giveUpTheFunc()<br>
}<br>
<br>
struct S {<br>
        func giveUpTheFunc()<br>
}<br>
<br>
extension S: P {}<br>
<br>
Solution #3: No keyword, but extensions that conform to protocols can’t have anything other than protocol conformances unless they’re private.<br>
<br>
protocol P {<br>
        func giveUpTheFunc()<br>
}<br>
<br>
struct S {}<br>
<br>
extension S: P {<br>
        func giveUpTheFunc() {}<br>
        func tearTheRoofOffTheSucker() {} // error!<br>
}<br>
<br>
but this is okay:<br>
<br>
extension S: P {<br>
        func giveUpTheFunc() {<br>
                tearTheRoofOffTheSucker()<br>
        }<br>
<br>
        private func tearTheRoofOffTheSucker() {} // works :-)<br>
}<br>
<br>
There are definitely a range of ways to make protocol conformance more explicit. Which one is the best, I’m not sure, but we could probably flesh out the pros and cons of these, as well as any other options that I haven’t thought of, with some discussion.<br>
<span class=""><font color="#888888"><br>
Charles<br></font></span></blockquote><div><br></div><div><br></div><div>Sure, I too am not convinced we&#39;ve exhausted all the design possibilities. Here are some previous related threads (including one launched by a core team member):</div><div><br></div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005380.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005380.html</a> <br></div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011792.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011792.html</a><br></div><div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015920.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015920.html</a></div></div><div><br></div><div>Somewhat related, but definitely a different topic:</div><div><br></div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018286.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018286.html</a></div><div><br></div></div></div></div>