I think that&#39;s a simple and elegant solution. The private member exception can be extended so that any member with less visibility than the minimum of the type and protocol visibility would be allowed.<br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 20, 2016 at 09:48 Martin Waitz &lt;<a href="mailto:tali@admingilde.org">tali@admingilde.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everybody,<br>
<br>
Several suggestions are floating around about explicitly marking a<br>
method to implement a protocol requirement.<br>
<br>
E.g.:<br>
<br>
&gt; class Foo : Bar {<br>
&gt;       implement func foo() {...}<br>
&gt; }<br>
<br>
However, with extensions we can already do something very similar:<br>
<br>
   class Foo {<br>
       ....<br>
   }<br>
   extension Foo: Bar {<br>
       func foo() {...}<br>
   }<br>
<br>
Maybe simply adding a new warning would already help.<br>
Extensions which introduce new protocol conformances could be reserved<br>
for those methods which are already defined within the protocol.<br>
Whenever such an extension contains an unrecognized method, we could<br>
issue a warning.<br>
Or maybe even an error, but we should allow private methods as an<br>
exception (for helper functions which are clearly not related to the<br>
protocol).<br>
<br>
This way, when the programmer wants to make sure that her new method is<br>
used by a protocol then she can simply put that method in an extension.<br>
<br>
--<br>
Martin<br>
</blockquote></div>