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. On Tue, Sep 20, 2016 at 10:14 Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:
> > > extension P { > > implement func foo() -> [String : String] { return [:] } > > } > > Yes, it seems like we need `implement` (or `override` as another > suggestion) in protocol extension also just for the same reasons - be clear > about our intention regarding implementing the requirement, to show that > this func *depends* on the previous definition of P protocol and to avoid > possible mistakes related to protocol conformance. > > On 20.09.2016 17:38, Charles Srstka wrote: > >> On Sep 20, 2016, at 8:17 AM, Vladimir.S via swift-evolution > >> <swift-evolution@swift.org <mailto: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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution