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.
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.
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.
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.
Effect on ABI stability
This has no effect on ABI stability
Effect on API resilience
This has no effect on API resilience
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
