[swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Vladimir.S]

Hmm..

What about such synthetic scenario:

at the moment of writing our code we have:

public protocol MyProtocol {
   func foo()
}

public struct StructA:MyProtocol {
   func foo()
}

public struct StructB:MyProtocol {
   func foo()
}

and have

public protocol ExtraProtocol1 {
   func bar()
}

public protocol ExtraProtocol2 {
   func blort()
}

then we actually can have such code:

func f(p: MyProtocol) {
   if let a = p as? struct<StructA, ExtraProtocol1> {
      a.foo()
      a.bar()
   }
   else
   if let b = p as? struct<StructB, ExtraProtocol2> {
      b.foo()
      b.blort()
   }
}

as we can(as example) expect that in 3rd party code someone will do:

extension StructA: ExtraProtocol1 {
   func bar() {}
}

extension StructB: ExtraProtocol2 {
   func blort() {}
}



On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
>>         'struct<>' does seem redundant unless it becomes subtypeable. If
>>         you want a struct which conforms to several protocols, protocol<>
>>         already covers this.
>>
>>     I think this is not correct. Lets check this example:
>>
>>     func foo(value: SomeProtocol) {
>>
>>         if let a = value as? struct<StructA, SomeProtocol> { /* do
>>     something with a */ }
>>
>>         else if let b = value as? struct<StructB, SomeProtocol> { /* do
>>     something with b */ }
>>
>>     }
>>
>>     In this scenario you’ll be able to access properties and functions
>>     from `StructA` or `StructB` which might not be covered by
>>     `SomeProtocol`. Everything is merged nicely into one instance. But
>>     you are right it depends on the use-case.
>>
>>
>> There is no need to include the protocol here.   Just do this:
>>
>> if let a = value as? StructA { use a }
>>
> Whoops, I forgot that this will do the trick. I apologize for any confusion
> here, you are totally right.
>
> That been said, do we really need `type<>` aka. `all<>` for value types? I
> need to rethink this part of the proposal. Is there any use-case where we
> would need this (any scenario for the future Swift version also counts)?
>
> If we had `all<>` in Swift already for extendable reference types and one
> day structs would become subtypeable, this wouldn’t be a huge problem to
> upgrade `all<>` for structs I guess.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>