[swift-dev] Default implementations from protocols and ABI stability
Philippe Hausler
phausler at apple.com
Thu Jan 11 12:25:48 CST 2018
Given the tentative ideas already being worked on for ABI stability what would be the place that code associated with a default implementation of a method on a protocol live?
e.g.
FooKit has some code that is similar to this:
public struct SomeOptions : RawRepresentable {
public private(set) var rawValue: Int
public init(rawValue: Int) { self.rawValue = rawValue }
public static let sensible = SomeOptions(rawValue: 1 << 0)
public static let maybeWillBeBetterLater = SomeOptions(rawValue: 1 << 1)
}
public protocol Somethingable {
func contrive()
func contrive(options: SomeOptions)
}
extension Somethingable {
func contrive() { contrive(options: .sensible) }
}
Then later on in a newer version of FooKit maybeWillBeBetterLater is now MUCH better and should be the default option so the code is updated to look like this:
public struct SomeOptions : RawRepresentable {
public private(set) var rawValue: Int
public init(rawValue: Int) { self.rawValue = rawValue }
public static let sensible = SomeOptions(rawValue: 1 << 0)
public static let maybeWillBeBetterLater = SomeOptions(rawValue: 1 << 1)
}
public protocol Somethingable {
func contrive()
func contrive(options: SomeOptions)
}
extension Somethingable {
func contrive() { contrive(options: .maybeWillBeBetterLater) }
}
For apps compiled with FooKit when they are run with the new version of FooKit do they get the behavior of sensible or maybeWillBeBetterLater?
Basically this is a question of where will the code for protocol extensions that are adopted across module boundaries live?
This interestingly applies to things like Collection and other standard library protocols and has some potential drawbacks and benefits from either way of it possibly working.
Thanks in advance for indulging my curiosity.
Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20180111/15dcd884/attachment.html>
More information about the swift-dev
mailing list