Comments in-line below.<br><br>On Thursday, 7 January 2016, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Another option might be to allow imported definitions to be used by a<br>
> conformance without the `override` marking to support retroactive 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</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote>I don't like this solution because the compiler produces poor error messages. It says that the type that implements the protocol doesn't conform to the protocol in all three cases described below. Whereas if override were required the compiler would say one of:<div><br></div><div>1. If the method was completely absent or there was a typo and no override the compiler could identify the missing method as an error on the type.</div><div>2. If the method had the same signature as a protocol method but no override (or had final) the compiler could say that override is required and importantly identify the method at fault</div><div>3. If the method had override but a typo the compiler could say that it does not override a method and importantly identify the method at fault.</div><div>4. If the method had both final and override the compiler could say that both not allowed and importantly identify the method at fault.<br><div><br></div><div>Which is much more fine grained and informative.<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote>I would prefer final to be required so that it is clear that this is a static dispatch.<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>> 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 being<br>
> implemented instead 'masks' (would that be the right word?) a statically<br>
> dispatched method in a protocol extension which can nonetheless be 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 in<br>
> the types.<br>
><br>
> What do I mean by that? Well, imagine you need generic access to the `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 to<br>
> be used to satisfy a requirement. Requiring a keyword like you suggest 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 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 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>
</blockquote></div></div><br><br>-- <br> -- Howard.<br><br>