The point is that without the requirement of both final and override the compiler doesn&#39;t know in detail what the problem is; just that there is a problem, it doesn&#39;t have enough information (it doesn&#39;t know the programmers intention - override and final clarify that intension). That is irrespective of how the compiler is written.<br><br>On Thursday, 7 January 2016, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; I don&#39;t like this solution because the compiler produces poor error<br>
&gt; messages. It says that the type that implements the protocol doesn&#39;t conform<br>
&gt; to the protocol in all three cases described below. Whereas if override were<br>
&gt; required the compiler would say one of:<br>
<br>
I completely agree that the compiler&#39;s error messages are currently<br>
vague and unhelpful. I don&#39;t have any experience in terms of how the<br>
compiler goes about its job, but it seems to me that it&#39;s an<br>
orthogonal issue? Whether `override` is required everywhere or no, if<br>
the compiler has enough information to know that the type is<br>
nonconforming, surely it could be spruced up to know which methods or<br>
properties are missing even while maintaining today&#39;s syntax? Someone<br>
who&#39;s expert in this could probably chime in here. I get the sense<br>
from this list that the community and core team are not in favor of<br>
changing syntax only to make up for deficiencies in tooling, though<br>
honestly I don&#39;t think the syntax would be worse off if we do it your<br>
way.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; I would prefer final to be required so that it is clear that this is a<br>
&gt; static dispatch.<br>
<br>
I&#39;ve tried to follow the other thread about this. I&#39;m not clear that I<br>
fully grasp the proposal but that&#39;s my fault. Something isn&#39;t clicking<br>
about how final (which I understand in the context of class<br>
hierarchies) works in the context of protocol extensions. Would this<br>
mean that if a protocol extension defines a statically dispatched and<br>
therefore mandatory &#39;final&#39; method foo() that I&#39;m no longer allowed to<br>
have a method foo() in a conforming class? That seems like it could<br>
make a lot of things blow up especially in the context of retroactive<br>
modeling as discussed above. Perhaps I&#39;m just not understanding.<br>
<br>
<br>
On Wed, Jan 6, 2016 at 5:56 PM, Howard Lovatt &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;howard.lovatt@gmail.com&#39;)">howard.lovatt@gmail.com</a>&gt; wrote:<br>
&gt; Comments in-line below.<br>
&gt;<br>
&gt;<br>
&gt; On Thursday, 7 January 2016, Xiaodi Wu via swift-evolution<br>
&gt; &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; Another option might be to allow imported definitions to be used by a<br>
&gt;&gt; &gt; conformance without the `override` marking to support retroactive<br>
&gt;&gt; &gt; modeling<br>
&gt;&gt; &gt; while requiring definitions in the same module as the conformance to<br>
&gt;&gt; &gt; explicitly specify the `override`.<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s an interesting suggestion. I don&#39;t think I&#39;d prefer that<br>
&gt;&gt; solution, though, because I would imagine that it&#39;s during retroactive<br>
&gt;&gt; modeling of someone else&#39;s stuff that ambiguity regarding what&#39;s<br>
&gt;&gt; overridden or not might occur.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve been slow in fully understanding Greg Parker&#39;s feedback, but on<br>
&gt;&gt; reflection it may be the only way to satisfy all use cases. In<br>
&gt;&gt; Thorsten&#39;s scenario where neither the protocol and its extension nor<br>
&gt;&gt; the type is under the control of the user, making the type conform to<br>
&gt;&gt; the protocol would either require no keyword requirements regarding<br>
&gt;&gt; overriding methods (as it is, and as you suggest) or else a syntax to<br>
&gt;&gt; indicate an overriding method must exist *within the extension that<br>
&gt;&gt; conforms a type to a protocol* (as Greg suggests).<br>
&gt;&gt;<br>
&gt;&gt; Can I propose an amended solution then?<br>
&gt;&gt;<br>
&gt;&gt; (1) When a protocol requires a method (or property getter/setter,<br>
&gt;&gt; etc.) but doesn&#39;t provide a default implementation, no keyword is used<br>
&gt;&gt; anywhere since all conforming types must provide their own<br>
&gt;&gt; implementation--I suppose a requirement could be made for a keyword,<br>
&gt;&gt; but I don&#39;t know that it adds much in terms of guarding against<br>
&gt;&gt; unintended behavior; I guess that can be a continued point of<br>
&gt;&gt; discussion<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; I don&#39;t like this solution because the compiler produces poor error<br>
&gt; messages. It says that the type that implements the protocol doesn&#39;t conform<br>
&gt; to the protocol in all three cases described below. Whereas if override were<br>
&gt; required the compiler would say one of:<br>
&gt;<br>
&gt; 1. If the method was completely absent or there was a typo and no override<br>
&gt; the compiler could identify the missing method as an error on the type.<br>
&gt; 2. If the method had the same signature as a protocol method but no override<br>
&gt; (or had final) the compiler could say that override is required and<br>
&gt; importantly identify the method at fault<br>
&gt; 3. If the method had override but a typo the compiler could say that it does<br>
&gt; not override a method and importantly identify the method at fault.<br>
&gt; 4. If the method had both final and override the compiler could say that<br>
&gt; both not allowed and importantly identify the method at fault.<br>
&gt;<br>
&gt; Which is much more fine grained and informative.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; (2) When a protocol doesn&#39;t declare a method but an extension to the<br>
&gt;&gt; protocol provides one, types implementing a method with the same<br>
&gt;&gt; signature *must not* declare it to be overriding; such protocol<br>
&gt;&gt; extension methods are not overridden because they can be invoked after<br>
&gt;&gt; upcasting<br>
&gt;&gt;<br>
&gt; I would prefer final to be required so that it is clear that this is a<br>
&gt; static dispatch.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; (3) When a protocol does declare a method, and an extension to the<br>
&gt;&gt; protocol provides a default implementation, then to override that<br>
&gt;&gt; implementation *either* the implementing type *or* an extension must<br>
&gt;&gt; use the keyword `override`<br>
&gt;&gt;<br>
&gt;&gt; (3a) In the case of an implementing type, `override func` is used<br>
&gt;&gt; instead of `func`, just as in the case of a class overriding a<br>
&gt;&gt; superclass method<br>
&gt;&gt;<br>
&gt;&gt; (3b) In the case of an extension to a type (this is the syntax I could<br>
&gt;&gt; come up with, but maybe it&#39;ll be objectionable in other ways), a<br>
&gt;&gt; method in an existing class can be retroactively made overriding by<br>
&gt;&gt; declaring `override [method signature]` with no body, similar to the<br>
&gt;&gt; way that a method is declared inside a protocol; by analogy, an<br>
&gt;&gt; overriding getter might use the syntax<br>
&gt;&gt;<br>
&gt;&gt; extension Int: BoundedType {<br>
&gt;&gt;     static var min { override get }<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; I think the syntax proposed in (3b) has the virtue of not requiring<br>
&gt;&gt; additional keywords, being sufficiently similar to (3a) so that it&#39;s<br>
&gt;&gt; not surprising, but still sufficiently unique in that the syntax is<br>
&gt;&gt; not currently valid code and thus isn&#39;t currently used to mean<br>
&gt;&gt; anything else.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jan 6, 2016 at 8:21 AM, Matthew Johnson &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;matthew@anandabits.com&#39;)">matthew@anandabits.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Jan 6, 2016, at 3:48 AM, Greg Parker via swift-evolution<br>
&gt;&gt; &gt; &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution<br>
&gt;&gt; &gt; &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Taking inspiration from syntax used for methods in classes that override<br>
&gt;&gt; &gt; methods in superclasses, require methods that override dynamically<br>
&gt;&gt; &gt; dispatched default implementations in protocol extensions to use the<br>
&gt;&gt; &gt; override keyword. Likewise, forbid the override keyword if the method<br>
&gt;&gt; &gt; being<br>
&gt;&gt; &gt; implemented instead &#39;masks&#39; (would that be the right word?) a statically<br>
&gt;&gt; &gt; dispatched method in a protocol extension which can nonetheless be<br>
&gt;&gt; &gt; invoked<br>
&gt;&gt; &gt; by upcasting to the protocol.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; This has been suggested before, usually in the form of a separate<br>
&gt;&gt; &gt; `implement` keyword. The main problem is that it makes it impossible to<br>
&gt;&gt; &gt; write a protocol after the fact which formalizes some existing pattern<br>
&gt;&gt; &gt; in<br>
&gt;&gt; &gt; the types.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; What do I mean by that? Well, imagine you need generic access to the<br>
&gt;&gt; &gt; `min`<br>
&gt;&gt; &gt; and `max` static properties of the various integer types. There&#39;s no<br>
&gt;&gt; &gt; existing protocol that includes those members. But you can write one and<br>
&gt;&gt; &gt; then extend the integer types to conform to your new protocol:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; protocol BoundedIntegerType: IntegerType {<br>
&gt;&gt; &gt; static var min: Self { get }<br>
&gt;&gt; &gt; static var max: Self { get }<br>
&gt;&gt; &gt; }<br>
&gt;&gt; &gt; extension Int: BoundedType {}<br>
&gt;&gt; &gt; extension Int8: BoundedType {}<br>
&gt;&gt; &gt; extension Int16: BoundedType {}<br>
&gt;&gt; &gt; extension Int32: BoundedType {}<br>
&gt;&gt; &gt; extension Int64: BoundedType {}<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; func printLowestPossibleValueOfValue&lt;Integer: BoundedIntegerType&gt;(x:<br>
&gt;&gt; &gt; Integer) {<br>
&gt;&gt; &gt; print(Integer.min)<br>
&gt;&gt; &gt; }<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; This only works because `min` and `max` *don&#39;t* need any special marking<br>
&gt;&gt; &gt; to<br>
&gt;&gt; &gt; be used to satisfy a requirement. Requiring a keyword like you suggest<br>
&gt;&gt; &gt; would<br>
&gt;&gt; &gt; remove that feature.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Possible solution: if you want a new protocol adoption to map to some<br>
&gt;&gt; &gt; existing method or property then you must explicitly write that. You<br>
&gt;&gt; &gt; can&#39;t<br>
&gt;&gt; &gt; just adopt the protocol in an empty extension.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;    extension Int: BoundedType {<br>
&gt;&gt; &gt;        static var min = Int.min<br>
&gt;&gt; &gt;        static var max = Int.max<br>
&gt;&gt; &gt;    }<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; but with some other syntax that isn&#39;t ambiguous. Code completion and<br>
&gt;&gt; &gt; compiler fix-its could suggest this when the class already implements<br>
&gt;&gt; &gt; something suitable.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Another option might be to allow imported definitions to be used by a<br>
&gt;&gt; &gt; conformance without the `override` marking to support retroactive<br>
&gt;&gt; &gt; modeling<br>
&gt;&gt; &gt; while requiring definitions in the same module as the conformance to<br>
&gt;&gt; &gt; explicitly specify the `override`.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Greg Parker     <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;gparker@apple.com&#39;)">gparker@apple.com</a>     Runtime Wrangler<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; swift-evolution mailing list<br>
&gt;&gt; &gt; <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a><br>
&gt;&gt; &gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt;   -- Howard.<br>
&gt;<br>
</blockquote><br><br>-- <br>  -- Howard.<br><br>