As I mentioned above, I agree that better diagnostics for near-misses are necessary, but they are possible without new syntax. There is no win in avoiding unintentional behavior because, without a default implementation, these issues are caught at compile time already.<br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 20, 2016 at 10:14 Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> extension P {<br>
> implement func foo() -> [String : String] { return [:] }<br>
> }<br>
<br>
Yes, it seems like we need `implement` (or `override` as another<br>
suggestion) in protocol extension also just for the same reasons - be clear<br>
about our intention regarding implementing the requirement, to show that<br>
this func *depends* on the previous definition of P protocol and to avoid<br>
possible mistakes related to protocol conformance.<br>
<br>
On 20.09.2016 17:38, Charles Srstka wrote:<br>
>> On Sep 20, 2016, at 8:17 AM, Vladimir.S via swift-evolution<br>
>> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
>><br>
>> On 20.09.2016 3:03, Xiaodi Wu via swift-evolution wrote:<br>
>>> I definitely think Vladimir's suggestion is a great starting point, IMO.<br>
>>><br>
>>> However, I think it could be improved in one key respect where previous<br>
>>> proposals using `override` are superior. Namely, the proposed `implement`<br>
>>> keyword adds no additional safety when a type implements a protocol<br>
>>> requirement that doesn't have a default implementation. This is because, if<br>
>><br>
>> Yes, *at the moment of writing* the type's code there could be no default<br>
>> implementation for protocol requirement. But, *at the moment of<br>
>> compilation* such default implementation could appear.<br>
>><br>
>> Let's discuss such scenario in case we'll take your suggestion:<br>
>><br>
>> You got SomeClass.swift file, 3rd party file you don't want to change or<br>
>> changes are not allowed. Content:<br>
>><br>
>> public protocol SomeProtocol {<br>
>> func foo()<br>
>> }<br>
>><br>
>> public class SomeClass : SomeProtocol {<br>
>> func foo() {...} // no default implementation *at the moment of writing*,<br>
>> no need in `overload`<br>
>> }<br>
>><br>
>> Now, you adds SomeClass.swift file to your project and in some *other*<br>
>> file you write:<br>
>><br>
>> extension SomeProtocol {<br>
>> func foo() {...}<br>
>> }<br>
>><br>
>> As you see, you don't control the SomeClass.swift but you suggest in this<br>
>> case SomeClass.foo() should be defined with `override`.<br>
>><br>
>> With 'implement' SomeClass.foo() will be marked initially and will save<br>
>> us if protocol's requirement PLUS default implementation changed.<br>
><br>
> Requiring the ‘implement’ keyword can help us even if no default<br>
> implementation is involved. Consider:<br>
><br>
> protocol P {<br>
> func foo() -> [String : Any]<br>
> }<br>
><br>
> struct S : P {<br>
> func foo() -> [String : String] { return [:] }<br>
> }<br>
><br>
> We will get an error here that S does not conform to P. However, this is<br>
> not the correct error, since S in fact *tries* to conform to P, but it has<br>
> a mistake in a method signature. This misleads us as to the true nature of<br>
> the problem, and if S has enough members in it that we fail to spot the<br>
> existing foo(), we might solve the problem by reimplementing foo(), and<br>
> leaving the original foo() as dangling dead code. Having an ‘implement’<br>
> keyword on the existing foo() function would change the compiler error to<br>
> let us know that we have an existing foo() that is incorrectly declared.<br>
><br>
> In addition, ‘implement’ can help us when the declaration in question *is*<br>
> the default implementation:<br>
><br>
> protocol P {<br>
> func foo() -> [String : Any]<br>
> }<br>
><br>
> extension P {<br>
> implement func foo() -> [String : String] { return [:] }<br>
> }<br>
><br>
> Here we will get an error with the proposed ‘implement’ keyword, because<br>
> foo() does not have a signature matching anything in the protocol, whereas<br>
> without ‘implement’ we would happily and silently generate a useless<br>
> dangling function that would never be used, and then pass the buck to the<br>
> concrete type that implements P:<br>
><br>
> protocol P {<br>
> func foo() -> [String : Any]<br>
> }<br>
><br>
> extension P {<br>
> func foo() -> [String : String] { return [:] } // The error is here:<br>
> }<br>
><br>
> struct S : P {} // But it gets reported here.<br>
><br>
> Charles<br>
><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>