If we really want to be overkill, we could use `required` for implementing an un-defaulted protocol requirement, `override` for implementing a defaulted protocol requirement, and `default` for implementing a protocol requirement in a protocol extension.
I think this might be more verbose than necessary, but I think it is at least worth exploring some subset of those keywords. They all reuse existing ones too, which is mostly a plus. The biggest benefit I see from these is confidence that what you wrote satisfies your expectations. Just like `try` is required to document at the call-site that a method throws and like argument labels are required to document at the call-site the usage of each parameter, it's reasonable to require these keywords to document these expectations at the implementation-site. If you forget them, the compiler can easily remind you. Requiring `override` and/or `required` would make it clear that you're actually implementing the protocol. It's too easily to make a typo and define a completely unrelated method. If the requirement is defaulted, you would never know until runtime weirdness. These keywords make protocol conformance less stringily typed. I'm +1 on this idea in some form (but not necessarily what I suggested). > On Aug 24, 2016, at 10:13 AM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org> wrote: > > Requiring "override" when anything overrides a method defined in a protocol > extension should be added - structure and enumerated included, of course. > > Protocol extensions added inheritance to structs and enums and this should be > made explicit. > > Sent from my iPad > > On Aug 24, 2016, at 12:55 AM, Charles Srstka via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Aug 24, 2016, at 1:20 AM, Robert Widmann <devteam.cod...@gmail.com >>> <mailto:devteam.cod...@gmail.com>> wrote: >>> 2016/08/23 20:52、Charles Srstka <cocoa...@charlessoft.com >>> <mailto:cocoa...@charlessoft.com>> のメッセージ: >>> >>>>> On Aug 23, 2016, at 10:34 PM, Robert Widmann <devteam.cod...@gmail.com >>>>> <mailto:devteam.cod...@gmail.com>> wrote: >>>>> >>>>> 2016/08/23 15:29、Charles Srstka <cocoa...@charlessoft.com >>>>> <mailto:cocoa...@charlessoft.com>> のメッセージ: >>>>> >>>>>>> On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>> >>>>>>> 2016/08/22 14:30、David Cordero via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ: >>>>>>> >>>>>>>> >>>>>>>> The problem: >>>>>>>> At the moment, looking at the code of a class or a struct implementing >>>>>>>> a protocol, it is hard to know what methods are actually implementing >>>>>>>> the protocol and what other methods are just part of the code of the >>>>>>>> class or struct. >>>>>>>> >>>>>>> >>>>>>> That seems like a feature, not a bug. Why should I as an author care >>>>>>> whether a method contributes to a protocol conformance or not if the >>>>>>> compiler can tell me that kind of information itself? >>>>>> >>>>>> Being able to reason about your code, what it does, and what it’s for is >>>>>> undesirable? >>>>> >>>>> That's not an answer to the question I asked. Why is this significant >>>>> enough to warrant an entire keyword? The clutter of a whole keyword that >>>>> does nothing but wait for a developer to make a source-compatible >>>>> binary-breaking change to an interface does not seem worth it. Maybe you >>>>> can convince me otherwise. >>>> >>>> Same reason overriding a class method warrants a keyword. It expresses the >>>> purpose more clearly, and allows the compiler to catch mistakes for us. >>>> >>> >>> That's just it: The class of mistakes one can make by not being explicit >>> about overrides is significantly more dangerous than the class of mistakes >>> caused by dead code leftover from trimming protocols. >> >> I am in the middle of a large refactor of code that was originally >> Objective-C and then Swift written like Objective-C, to more idiomatic >> protocol-oriented Swift. I am finding that in Swift’s POP idiom, protocols >> with overrides are serving very nearly the same purpose that overrides were >> serving in the old design; hence, I don’t really think either is more or >> less dangerous than the other. >> >>>>>>>> ``` >>>>>>>> protocol MyProtocol { >>>>>>>> func myMethod() -> String >>>>>>>> } >>>>>>>> >>>>>>>> class MyClass: MyProtocol { >>>>>>>> >>>>>>>> conform func myMethod() -> String { >>>>>>>> return "Yuhuuu,I am conforming \\o// <smb://o//>" >>>>>>>> } >>>>>>>> >>>>>>>> func whatever() { >>>>>>>> print("I am a boring method and I don't conform anything") >>>>>>>> } >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> It would be something similar to the current keyword `override` but >>>>>>>> for protocols. >>>>>>>> >>>>>>>> Apart from improving code readability, It would allow the detection, >>>>>>>> in compilation time, of errors due to code evolution. For example >>>>>>>> redundant methods that no longer conform anything once the requirement >>>>>>>> is removed from the protocol for whatever reason. >>>>>>> >>>>>>> If you make a breaking change to a protocol like this, you should have >>>>>>> gone through a deprecation cycle to indicate to your clients the >>>>>>> appropriate changes you're going to make to the protocol. This aspect >>>>>>> of the change seems to if not encourage, highlight, bad behavior. >>>>>> >>>>>> What if it’s your own code and all the callers are internal? What if >>>>>> you’re still developing the protocol and haven’t released the API >>>>>> interface yet? >>>>> >>>>> Then your concerns are local enough that you know where all >>>>> implementations of the protocol lie and whether they require deletion or >>>>> not. The point about deprecation cycles still stands in all the cases >>>>> you mention. Just because the interface is private doesn't mean you >>>>> can't take responsibility for keeping it as clean as you can. >>>>> >>>>>> >>>>>> Charles >>>>>> >>>>> >>>>> tl;dr It seems like all of this can be subsumed by us warning about dead >>>>> code. >>>> >>>> Did you look at my examples earlier in the thread? Neither of those would >>>> be caught by warning about dead code. >>> >>> The example involving the default implementation is most compelling, but it >>> indicates that your proposed solution should focus on the protocol >>> extension and not the implementing declaration. Perhaps reusing one of our >>> existing keywords can help here >>> >>> protocol P { >>> func foo() {} >>> } >>> >>> extension P { >>> default func foo() {} >>> } >>> >>> struct S: P {} >>> >>> Of course, this change would be potentially source-breaking either way - I >>> don't like the sound of an "optional keyword”. >> >> I can come up with a similar example without the mistake being in the >> extension, though: >> >> protocol P { >> func foo() {} >> } >> >> extension P { >> func foo() { print(“Default Behavior”) } >> } >> >> struct S: P { >> func foo() { print(“Specific Behavior”) } >> } >> >> So far, so good. But now I realize that the original protocol needs an >> argument: >> >> protocol P { >> func foo(bar: String) {} >> } >> >> extension P { >> func foo(bar: String) { print(“Default Behavior; bar is \(bar)”) } >> } >> >> struct S: P { >> func foo() { print(“Specific Behavior”) } // Whoops, forgot to update >> this method, and now it won’t get called—and we of course won’t see the >> carnage until runtime. >> } >> >>> Either way, we can all agree we need better diagnostics around these cases. >> >> No doubt. >> >> Charles >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
