[swift-evolution] Specified Protocol Conformances in Subclasses

[David Waite]

The getter is covariant while the setter is contravariant. The result is read/write properties are invariant.

Objective-C basically considers declared types to be advisory (to generate compiler warnings). In reality, both delegate properties are of type ‘id’, with type issues surfacing at runtime.

-DW

> On Mar 10, 2017, at 5:08 AM, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi everyone. I found something odd that seems baked into how Cocoa Touch does protocols, but Swift cannot model it:
> 
> 
> @interface UIScrollView: UIView
> 
> @property (weak, nonatomic) id <UIScrollViewDelegate> delegate;
> 
> @end
> 
> @interface UITableView: UIScrollView
> 
> @property (weak, nonatomic) id <UITableViewDelegate> delegate;
> 
> @end
> 
> @protocol UITableViewDelegate: UIScrollViewDelegate
> ...
> @end
> 
> 
> 
> Subclasses can further specify the conformance of a property’s protocol-conforming object to state a further type on that property. I tried to do something extremely similar today in Swift, and it failed, saying the protocols were different:
> 
> 
> class SourceBar: UIScrollView {
> 	
> 	override var delegate: SourceBarDelegate? {
> 		get { return super.delegate as? SourceBarDelegate }
> 		set { super.delegate = newValue }
> 	}
> 
> } 
> 
> 
> @objc protocol SourceBarDelegate: UIScrollViewDelegate {
> 	func foo()
> }
> 
> 
> Considering the fact that the protocol SourceBarDelegate conforms to UIScrollViewDelegate, I can’t see why this override should fail. Can anyone enlighten me as to why this is a limitation in the language?
> 
> Thanks,
> 
> Rod
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution