> On Sep 20, 2016, at 8:17 AM, Vladimir.S via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> On 20.09.2016 3:03, Xiaodi Wu via swift-evolution wrote:
>> I definitely think Vladimir's suggestion is a great starting point, IMO.
>> 
>> However, I think it could be improved in one key respect where previous
>> proposals using `override` are superior. Namely, the proposed `implement`
>> keyword adds no additional safety when a type implements a protocol
>> requirement that doesn't have a default implementation. This is because, if
> 
> Yes, *at the moment of writing* the type's code there could be no default 
> implementation for protocol requirement. But, *at the moment of compilation* 
> such default implementation could appear.
> 
> Let's discuss such scenario in case we'll take your suggestion:
> 
> You got SomeClass.swift file, 3rd party file you don't want to change or 
> changes are not allowed. Content:
> 
> public protocol SomeProtocol {
>       func foo()
> }
> 
> public class SomeClass : SomeProtocol {
>       func foo() {...} // no default implementation *at the moment of 
> writing*, no need in `overload`
> }
> 
> Now, you adds SomeClass.swift file to your project and in some *other* file 
> you write:
> 
> extension SomeProtocol {
>       func foo() {...}
> }
> 
> As you see, you don't control the SomeClass.swift but you suggest in this 
> case SomeClass.foo() should be defined with `override`.
> 
> With 'implement' SomeClass.foo() will be marked initially and will save us if 
> protocol's requirement PLUS default implementation changed.

Requiring the ‘implement’ keyword can help us even if no default implementation 
is involved. Consider:

protocol P {
        func foo() -> [String : Any]
}

struct S : P {
        func foo() -> [String : String] { return [:] }
}

We will get an error here that S does not conform to P. However, this is not 
the correct error, since S in fact *tries* to conform to P, but it has a 
mistake in a method signature. This misleads us as to the true nature of the 
problem, and if S has enough members in it that we fail to spot the existing 
foo(), we might solve the problem by reimplementing foo(), and leaving the 
original foo() as dangling dead code. Having an ‘implement’ keyword on the 
existing foo() function would change the compiler error to let us know that we 
have an existing foo() that is incorrectly declared.

In addition, ‘implement’ can help us when the declaration in question *is* the 
default implementation:

protocol P {
        func foo() -> [String : Any]
}

extension P {
        implement func foo() -> [String : String] { return [:] }
}

Here we will get an error with the proposed ‘implement’ keyword, because foo() 
does not have a signature matching anything in the protocol, whereas without 
‘implement’ we would happily and silently generate a useless dangling function 
that would never be used, and then pass the buck to the concrete type that 
implements P:

protocol P {
        func foo() -> [String : Any]
}

extension P {
        func foo() -> [String : String] { return [:] } // The error is here:
}

struct S : P {} // But it gets reported here.

Charles

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to