<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div>My understanding of Self is that it is a special generic parameter resolved by the type system to the type of the implementing structure. That resolution <b>must be invariant </b>because the implementing structure (here, non-final classes) can choose to yank the protocol's invariants out from under you when it is subclassed. Sure, retroactively, you can make things conform, but you also can't completely guarantee type safety with any kind of variance in Self in all cases. </div><div><br></div><div>On the other hand, using the protocol itself in either position says that you only wish to restrict yourself to the protocol itself, not some specific implementation. You are necessarily specifying an upper bound (here C) on the amount of "information" you can get out of the type, so it is possible to introduce variance because you will never violate the protocol's invariants by returning a subtype with a legal conformance.</div><div><br></div><div>Self doesn't mean two different things, your protocol declarations do!</div><div><br><div>~Robert Widmann</div></div><div><br>2015/12/28 11:49、Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><span>I have brought up the idea of a non-covarying Self a few times. </span><br><span></span><br><span>I was surprised to realize that Self is actually non-covarying when used for parameters in protocol declarations!</span><br><span></span><br><span>Here is an example demonstrating this:</span><br><span></span><br><span>protocol P {</span><br><span> func foo(s: Self)</span><br><span>}</span><br><span>protocol Q {</span><br><span> func bar() -> Self</span><br><span>}</span><br><span></span><br><span>class C: P {</span><br><span> // this works! Self as an argument type in the protocol declaration does not covary</span><br><span> func foo(c: C) {}</span><br><span>}</span><br><span></span><br><span>class D: C {}</span><br><span></span><br><span>extension C: Q {</span><br><span> // method ‘bar()’ in non-final class ‘C’ must return ‘Self’ to conform to protocol ‘Q'</span><br><span> func bar() -> C { return self } </span><br><span>}</span><br><span></span><br><span></span><br><span>It doesn’t make sense to allow a co-varying Self for parameters so I can understand how the current state might have arisen. At the same time, using Self to mean two different things is inconsistent, confusing and it doesn’t allow us to specify a non-covarying Self as a return type in protocol requirements. </span><br><span></span><br><span>As I have pointed out before, the ability to specify a non-covarying Self as a return type would make it possible to design a protocol that can be retroactively conformed to by non-final classes (such as those in Apple’s frameworks).</span><br><span></span><br><span>I think it would be a very good idea to introduce a non-covarying Self which would specify the type that adds conformance to the protocol and require this Self to be used in places where covariance is not possible, such as parameter types. It would also be allowed elsewhere, such as return types, making it easier to conform non-final classes when covariance is not required by the protocol.</span><br><span></span><br><span>One possible name is `ConformingSelf`. One thing I like about this name is that it makes it very clear that it is the type that introduces protocol conformance.</span><br><span></span><br><span>I’m interested in hearing thoughts on this.</span><br><span></span><br><span>Matthew</span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>