[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[T.J. Usiyan]

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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
>
> On Thu, Apr 28, 2016 at 9:40 PM, Erica Sadun <erica at ericasadun.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160430/1d6b72f6/attachment.html>