I would also love to have generic associated types in the language, I have a
lot of uses for them and, IIUC, supertype constraint would enable me to express
the following:
protocol Service {}
protocol WikiService: Service {} // methods not shown for conciseness
class DefaultWikiService: WikiService {}
class DemoWikiService: WikiService {}
class DataServiceManager {
private var registry = [String: Service]()
func register<S>(_ service: Service, ofType type: S.Type) where S: Service {
let key = "\(Swift.type(of: type))"
registry[key] = service
}
func service<S>(ofType type: S.Type) -> S where S: Service {
let key = "\(Swift.type(of: type))"
// It is a programmer error to expect a value for a not yet registered
type
guard let service = registry[key] as? S else {
fatalError("Service of type \(type) cannot be found. Please
register a service for that type before accessing it.")
}
return service
}
}
let manager = DataServiceManager()
if isDemoMode {
manager.register(DemoWikiService(), ofType: WikiService.self) // Currently:
error: in argument type 'WikiService.Protocol', 'WikiService' does not conform
to expected type 'Service'
} else {
manager.register(DefaultWikiService(), ofType: WikiService.self) //
Currently: error: in argument type 'WikiService.Protocol', 'WikiService' does
not conform to expected type 'Service'
}
If that's right, I'm also +1 on this :)
- Dennis
> On Nov 25, 2017, at 12:13 AM, Adrian Zubarev via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> In general this is more then welcome, so +1 for me.
>
> However I have one question:
>
> Could this allow support, or at least be a first step towards Swift allowing
> the following behaviour?
>
> ```
> extension MyProtocol where Self : SomeClass {
> static func getSubtypes<T>(ofType _: T.Type = T.self) -> [T] where T :
> Self { ... }
> }
> ```
>
> I would like to be able to upgrade `Self` to a class constraint, which then
> will allow me to only accept subtypes from T at compile time.
>
> Am 25. November 2017 um 00:03:23, Matthew Johnson via swift-evolution
> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:
>
>> One of the most frequent frustrations I encounter when writing generic code
>> in Swift is the requirement that supertype constraints be concrete. When I
>> mentioned this on Twitter
>> (https://twitter.com/anandabits/status/929958479598534656
>> <https://twitter.com/anandabits/status/929958479598534656>) Doug Gregor
>> mentioned that this feature is smaller and mostly straightforward to design
>> and implement (https://twitter.com/dgregor79/status/929975472779288576
>> <https://twitter.com/dgregor79/status/929975472779288576>).
>>
>> I currently have a PR open to add the high-level description of this feature
>> found below to the generics manifesto
>> (https://github.com/apple/swift/pull/13012
>> <https://github.com/apple/swift/pull/13012>):
>>
>> Currently, supertype constraints may only be specified using a concrete
>> class or protocol type. This prevents us from abstracting over the
>> supertype.
>>
>> ```swift
>> protocol P {
>> associatedtype Base
>> associatedtype Derived: Base
>> }
>> ```
>>
>> In the above example `Base` may be any type. `Derived` may be the same as
>> `Base` or may be _any_ subtype of `Base`. All subtype relationships
>> supported by Swift should be supported in this context including, but not
>> limited to, classes and subclasses, existentials and conforming concrete
>> types or refining existentials, `T?` and `T`, `((Base) -> Void)` and
>> `((Derived) -> Void)`, etc.
>>
>> Generalized supertype constraints would be accepted in all syntactic
>> locations where generic constraints are accepted.
>>
>> I would like to see generalized supertype constraints make it into Swift 5
>> if possible. I am not an implementer so I will not be able to bring a
>> proposal forward alone but am interested in collaborating with anyone
>> interested in working on implementation.
>>
>> I am also interested in hearing general feedback on this feature from the
>> community at large. Have you also found this limitation frustrating? In
>> what contexts? Does anyone have reservations about introducing this
>> capability? If so, what are they?
>>
>> Matthew
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
