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

[Vladimir.S]

I feel like this could be a useful feature. We can right now couple protocols

protocol A { func a() }
protocol B { func b() }

func z(o: protocol<A,B>) {
     o.a()
     o.b()
}

let o = some as! protocol<A, B>
o.a()
o.b()

But how to be if we need to specify some class/struct in addition to protocol?
So, if this feature could be implemented, I'm +1 on this `type<>` feature
Or probably we can allow class in protocol<>

On 11.05.2016 21:06, Adrian Zubarev via swift-evolution wrote:
> Sorry for pushing this back, but I really would like to read any feedback
> for this idea of mine. ;)
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 4. Mai 2016 bei 22:38:33, Adrian Zubarev
> (adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>)
> schrieb:
>
>> This one have bothered me for days, since the idea came to my mind.
>>
>> I don't want to be too futuristic so here are my first thoughts.
>>
>> What if Swift 3 would have the ability to merge types and protocols together?
>>
>> Sure we will see generic typealias in Swift 3 but it doesn't allow us
>> merge value types which conforms to specific protocols (if there is a need).
>>
>> protocol SomeProtocol {
>> func boo()
>> }
>>
>> // this use-case can be solved with generic typealias in Swift 3 (at
>> least for classes), but it is not the only one usecase of type merging
>> func foo(mergedInstance: type<UIView, SomeProtocol>) {
>> mergedInstance.removeFromSuperview() // just for the example
>> mergedInstance.boo()
>> }
>>
>> extension UIButton: SomeProtocol { /* implemnt boo() */ }
>>
>> let button: SomeProtocol = UIButton() // decouple UIButton first
>>
>> Ok now I want to use one instance as SomeProtocol and UIView.
>>
>> // another possible use-case
>> if let mergedView = button as? type<UIView, SomeProtocol> {
>> mergedView.removeFromSuperview() // just for the example
>> mergedView.boo()
>> }
>>
>> More detailed design:
>>
>> - type<> can contain only one value or reference type and n protocols
>> - value or reference type should always be the first type
>> - type<> should always contain at least 2 types (one value or reference
>> type and min. one protocol)
>> - reference types does represent one possible super/base type of the
>> actuall type
>>      * class A {}
>>      * class B: A {}
>>      * class C: B {}
>>      * possible types for B and C: type<B, AnyProtocolType, ...> or
>> type<A, AnyProtocolType, ...>
>> - the dynamicType/Self instance passed to type<> conforms to all
>> protocols type<> contains
>>
>> If there is more rules one would apply to this idea feel free to discuss
>> them here.
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>