I agree that a keyword indicating intent would be nice, but I can't get behind override if what you're doing is providing your own implementation. I understand that we are trying to avoid adding keywords but could `implement` or a synonym work? If you override something that your superclass implements then you wouldn't need the `implement` keyword, just `override`. This has the benefit of making it clear that the method came from a protocol and not a superclass.
TJ On Sat, Apr 30, 2016 at 6:01 AM, L. Mihalkovic via swift-evolution < [email protected]> wrote: > I like your example because it focusses on the scenarios I often have to > deal with: namely to inherit working code that is lacking flexibility > and/or abstraction (extensibility). Then I have to find convoluted ways to > retrofit some abstractions that do not alter the original code, but let me > introduce containment around it so that I can later remove it or extend it > *despite* its author. Java is very flexible in that matter, and it would > be great if swift did not get in the way in the name of focussing on > forward design (the design of the original author I usually have to dance > around). It is IMO part of the magic of typescript: that you can go so far > as organize conformance completely unbeknownst to the original loosely > (poorly?) defined code. > > Regards > (From mobile) > > On Apr 29, 2016, at 4:46 AM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > On Thu, Apr 28, 2016 at 9:40 PM, Erica Sadun <[email protected]> wrote: >> >> Without actually trying to understand the details of your math stuff: >> >> * If you add a required member in a declaration or extension that >> declares conformance, it is 'required'. >> * If it is already defaulted, it is `override required`. >> * If it is already defaulted but not required, it is `override` >> * If someone else implements the stuff, you still have to pull it in >> somehow, but if you do so by conforming to another protocol with an >> extension, it's not your business, so you don't use any keywords. >> >> You use keywords only for stuff that you specifically write, that >> clarifies the context in which you are writing it. If you do not own a >> protocol, an extension, or an implementation, you do not change or markup >> the protocol, extension, or implementation. You're just offering the >> compiler hints that your otherwise questionable decisions are fully >> intentional: when overriding an existing implementation and when conforming >> by supplying a required member. >> >> -- E, who still probably missed your point and again apologizes >> >> >> * If this is not Swift code it is not affected. >> * If it is Swift code, either use #if swift(>= blah) workarounds or >> propose that SwiftPM support earlier Swift compilation rules. >> * If this is adopted and the code is in Swift 3, it would already have >> compliances and you do not need to add anything >> >> Under what scenario could you possibly use 3rd party Swift 3 code >> (assuming adoption) that would require annotation/changing? >> > > Let's return to the toy example. Suppose I license the following code from > a third party. I am allowed to incorporate it unmodified into my project: > > ``` > // I cannot touch any of the following code > struct A { > func frobnicate() { print("A") } > } > struct B { > func frobnicate() { print("B") } > } > struct C { } > ``` > > The code above has three types that conform to no protocols. Nothing would > change on adoption of your proposal. As licensed to me from the third > party, there are no protocols for it to conform to. > > Now, in a separate file, as part of my own code, I want to conform these > three types to a protocol of my own design, Frobnicatable, and supply a > default `frobnicate()`: > > ``` > protocol Frobnicatable { > func frobnicate() > } > extension Frobnicatable { > func frobnicate() { print("Default") } > } > extension A: Frobnicatable { } > extension B: Frobnicatable { } > extension C: Frobnicatable { } > > let a = A() > a.frobnicate() // "A" > let c = C() > c.frobnicate() // "Default" > ``` > > It seems like there is nothing I can do to make this work upon > implementation of your proposal. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
