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