It sounds like what you want is an GADT-like adaptor gadget to try to bridge between these protocols across these specific types. With general disjuncts you’re subject to the open world assumption - that anybody that should conform to a (visible) protocol, can conform to that protocol - thus rendering any attempts to inspect the kind of thing you’ve got in the disjunct useless.
~Robert Widmann > On Feb 2, 2017, at 5:02 PM, Rex Fenley via swift-evolution > <[email protected]> wrote: > > But then any time as user of the pipeline I'm writing would like a new type > of collection they will be forced to inherit this new protocol vs one they're > already familiar with and which the collection may already conform too. > > On Thu, Feb 2, 2017 at 1:53 PM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> On Feb 2, 2017, at 3:46 PM, Rex Fenley <[email protected] >> <mailto:[email protected]>> wrote: >> >> My use case is RLMArray and it can't implement RangeReplaceableCollection >> though because `init` is unavailable, additionally, there's a lot of parts >> to the protocol that would take some time to implement correctly if I could. >> They offer a Swift type List that wraps RLMArray and does a bunch of stuff >> to implement RangeReplaceableCollection, but they discourage using their >> Swift library in mixed Obj-C/Swift projects and certain model objects simply >> couldn't use the List type anyway because they're also used in Obj-C and >> List is not @objc compliant. >> >> So this leaves me in situations where when I need to use Array or RLMArray I >> have to duplicate my code, not just in one place, but all the way down a >> pipeline in order to have my generics work with either >> RangeReplaceableCollection or RLMArray. >> >> If I could abstract the commonalities required by my application, I could >> just have a RLMArrayProtocol that has RLMArray's exposed function signatures >> and a new protocol Appendable = RangeReplaceableCollection | >> RLMArrayProtocol and this will type check all the way through the pipeline. >> >> tl;dr - if a function signature required by a protocol is marked unavailable >> on a class, then disjunction is necessary in order to bridge the two (or >> more) types without duplicating code. > > You should be able to solve this problem today by creating a custom protocol > that you use as a constraint in your generic code and providing conformances > for both Array and RLMArray. > >> >> On Thu, Feb 2, 2017 at 1:35 PM, Matthew Johnson <[email protected] >> <mailto:[email protected]>>wrote: >>> >>> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hello, I believe there was some discussion about this quite awhile ago. I >>> was wondering if there's any interest in including a protocol 'or' type >>> that would be the intersection of two protocols. This could be really >>> useful in situations where a framework that the user has no control over >>> implements a portion of some often used protocol. Such as specialized >>> collections from an Database framework that don't implement >>> RangeReplaceableCollection but have a set of methods that are equivalent. >>> The user can then implement a protocol that is the intersection of those >>> set of methods and not duplicate code. >> >> If the specialized collection in the database framework already provides >> functionality equivalent to `RangeReplaceableCollection` what you really >> want to do is just provide the conformance you’re looking for in an >> extension: >> >> extension SpecializedDatabaseCollection: RangeReplaceableCollection { >> // if necessary, provide forwarding wrappers where the member names don’t >> match up. >> } >> >> But in a case like this the framework itself really should provide this >> conformance out of the box. If they didn’t, maybe there is a good reason so >> you would want to find out why it wasn’t provided. >> >> Is there something you’re hoping to do that you can’t solve by simply >> extending the framework types? >> >>> >>> Simplified example: >>> >>> protocol Animal { >>> var hasEars: Bool { get } >>> func grow() >>> } >>> >>> protocol Plant { >>> var isGreen: Bool { get } >>> func grow() >>> } >>> >>> protocol LivingThing = Plant | Animal // or a different syntax >>> >>> LivingThing's is as follows >>> { >>> func grow() >>> } >>> >>> -- >>> Rex Fenley | IOS DEVELOPER >>> >>> >>> Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | >>> FOLLOW US <https://twitter.com/remindhq> | LIKE US >>> <https://www.facebook.com/remindhq>_______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> >> >> -- >> Rex Fenley | IOS DEVELOPER >> >> >> Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | >> FOLLOW US <https://twitter.com/remindhq> | LIKE US >> <https://www.facebook.com/remindhq> > > > > -- > Rex Fenley | IOS DEVELOPER > > > Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | > FOLLOW US <https://twitter.com/remindhq> | LIKE US > <https://www.facebook.com/remindhq>_______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
