+1 for the fix. Solid and straightforward. On Thu, Mar 9, 2017 at 9:32 AM, Rod Brown via swift-evolution < [email protected]> wrote:
> There has been a lot of discussion around this design decision. > Personally, I’m with you: this should be allowed. Protocol extensions > should be defaults, nothing more. > > The rationale mentioned in Swift Evolution for discouraging this behaviour > tends to be that if you conform to the protocol, you should conform and > adhere to all its extensions as well, and that not doing so in the same way > will be inconsistent. > > I personally think this comes to the Type-first vs Protocol-first approach > and I think instances of types should have the final say in the behaviour > of the operation. While this would perform slightly worse, and could > potentially be unsafe, I think it is consistent with the fact that not all > implementers of a protocol behave exactly the same; indeed, if they did, > we’d only have one type per protocol, in which case, what is the point of a > protocol at all? Just do it with types. > > I love POP and protocol extensions but I’m tempered by the fact that not > all types implement protocols in the same ways, and we can’t predict ahead > of time where those differences will be needed. > > > On 10 Mar 2017, at 12:48 am, Adrian Zubarev via swift-evolution < > [email protected]> wrote: > > My question is why cannot the Base type override the default > implementation? I might want to override it, by calling the default > implementation and modifying the result for my needs. > > Something like that: > > protocol P { > func foo() -> Int > } > > extension P { > func foo() -> Int { > return 42 > } > } > > class Base : P { > override func foo() -> { > > return default.foo() * 100 > } > } > > The example is kept simple. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution ( > [email protected]) schrieb: > > > > Sent from my iPad > > On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution < > [email protected]> wrote: > > I think the fact that the type checker permits ‘final’ to appear inside > protocol extensions is an oversight and this probably does not even warrant > a proposal. I don’t think allowing this was ever part of the conceptual > model of protocol extensions at any point in time (if you recall they were > introduced ‘recently’, in Swift 2). If someone put together a PR which > makes ‘final’ in protocol extensions an error in Swift 4 mode (and a > warning in 3), I would merge it. > > FWIW that there is one restriction around the direct dispatch here we want > to lift, but it’s not related to this proposal. > > If you have a base class conforming to a protocol using default > requirements, eg > > protocol Proto { func f() } > extension Proto { func f() { } } > > class Base : Proto {} > > Currently the witness table for Base : Proto directly references the > extension method Proto.f. > > We want to allow this, at least inside the module: > > class Derived { > override func f() {} // does not work currently > } > > This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, > pointing at the extension method. The conformance will dispatch through the > vtable instead of directly calling the extension method. > > > Would this allow the override to call `Proto.f` through super? > > > Slava > > On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution < > [email protected]> wrote: > > Hey Folks, This draft proposal addresses starter bug SR-1762. I believe > this is in scope for Swift 4 since it impacts source compatibility. It's > not a very exciting proposal, but I think it will help make Swift a little > more consistent. > > https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7 > https://bugs.swift.org/browse/SR-1762 > > Thanks > > Brian > Introduction > > This proposal suggests removing support for the final keyword when > declaring a function in a protocol extension. The presence of the final > keyword > does not currently generate an error message, and it does not actually > modify the dispatch behavior in any way. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#motivation> > Motivation > > In the original protocol model of Swift, a developer could use the final > keyword > when declaring a function in a protocol extension to ensure the function > could not be overridden. This keyword has no use in Swift's current > protocol model, since functions in protocol extensions can not be > overridden and will always use direct dispatch. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#detailed-design>Detailed > design > > The compiler should generate an error or warning when the final keyword > is used on a function declaration inside of a protocol extension. This is > consistent with the use of final in structs and enumerations. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#source-compatibility>Source > compatibility > > This change will impact source compatibility. To maintain compatibility > with Swift 3, a warning will be generated in Swift 3 mode instead of an > error message. > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#effect-on-abi-stability>Effect > on ABI stability > > This has no effect on ABI stability > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#effect-on-api-resilience>Effect > on API resilience > > This has no effect on API resilience > > <https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7#alternatives-considered>Alternatives > considered > The only alternative would be to not fix this bug > _______________________________________________ > 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 > > > _______________________________________________ > 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
