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

[Adrian Zubarev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160504/29c204b0/attachment.html>