> On Sep 20, 2016, at 8:17 AM, Vladimir.S via swift-evolution
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
