[swift-evolution] [Completing Generics] Completing protocol extension diagnostics
Brent Royal-Gordon
brent at architechies.com
Fri Mar 4 01:06:16 CST 2016
> (B) and (C) could be mitigated by shadowing warnings, and we've also floated ideas for making them behave as intended, by implicitly forwarding protocol requirements into class methods to address (B) and/or introducing dynamic dispatch for protocol extensions to address (C).
For what it's worth, I've posted threads several times aimed at addressing (C) through better warnings and keywording, and each time I've gotten lost of feedback from people who just want it dynamically dispatched. I wasn't aware of (B), but my guess is that I'd have heard the same thing if I'd brought it up.
> - Adopting an explicit 'implements' modifier, in the spirit of 'override', to mark a declaration as being intended to fulfill a requirement. This adds boilerplate we'd like to avoid, and also interferes with retroactive modeling.
One possible way around that second issue is to permit you to mark the conformance itself as `implements` when you're doing retroactive modeling.
protocol Arithmetic {
func + (lhs: Self, rhs: Self) -> Self
func - (lhs: Self, rhs: Self) -> Self
func * (lhs: Self, rhs: Self) -> Self
func / (lhs: Self, rhs: Self) -> Self
}
extension Int: implements Arithmetic {}
extension Double: implements Arithmetic {}
If we just turned off the keyword requirement when the conformance was marked, people would abuse the feature, so perhaps it merely indicates that one or more members defined *outside* the current module implement the requirements. Any members *inside* the current module would still have to be individually marked. (And if the protocol wasn't at least partially implemented by external members, the `implements` in the conformance would be illegal.)
--
Brent Royal-Gordon
Architechies
More information about the swift-evolution
mailing list