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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
