[swift-evolution] Either protocol syntax

[Matthew Johnson]

> On Feb 2, 2017, at 3:46 PM, Rex Fenley <rex at remind101.com> 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 <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170202/0503db4b/attachment.html>