<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Jun 9, 2016, at 8:06 AM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">According to that code (which is in Decl.cpp), AnyObject (and Any) conforms to itself; no non-@objc protocol is allowed to conform to itself. An @objc protocol may or may not conform to itself, depending on some other conditions.</div></div></blockquote><div><br></div><div>Like I said... more sub-cases than your original statement, right?!</div><br><blockquote type="cite"><div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 9:19 PM, L. Mihalkovic &lt;<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline"><br class="">On Jun 8, 2016, at 9:43 PM, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div dir="ltr" class="">It's not possible, even with Swift's current implementation of existentials. A protocol type P isn't considered to conform to itself, thus the following is rejected:</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The rules are not that simple, I seem to recall reading in sourcecode that there are criteria that decide if that is true or not. And by default the variable conform_to_self is even TRUE</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="">let a : MyProtocol = // ...</div><div class="">func myFunc&lt;T : MyProtocol&gt;(x: T) {</div><div class="">&nbsp; // ....</div><div class="">}</div><div class="">myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type MyProtocol"</div></div><div class=""><br class=""></div><div class="">Changing how this works is probably worth a proposal by itself.</div><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution<span class="Apple-converted-space">&nbsp;</span><span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span><span class="Apple-converted-space">&nbsp;</span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="HOEnZb"><div class="h5"><br class="">&gt; Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;:<br class="">&gt;<br class="">&gt;<br class="">&gt; on Tue Jun 07 2016, Matthew Johnson &lt;<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a>&gt; wrote:<br class="">&gt;<br class="">&gt;&gt;&gt; On Jun 7, 2016, at 9:15 PM, Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>&gt; wrote:<br class="">&gt;&gt;&gt;<br class="">&gt;&gt;&gt;<br class="">&gt;&gt;&gt; on Tue Jun 07 2016, Matthew Johnson &lt;<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a><span class="Apple-converted-space">&nbsp;</span>&lt;<a href="http://matthew-at-anandabits.com/" rel="noreferrer" target="_blank" class="">http://matthew-at-anandabits.com/</a>&gt;&gt; wrote:<br class="">&gt;&gt;&gt;<br class="">&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt; On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt; on Tue Jun 07 2016, Matthew Johnson &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt;&gt;&gt; , but haven't realized<br class="">&gt;&gt;&gt;&gt;&gt;&gt;&gt; that if you step around the type relationships encoded in Self<br class="">&gt;&gt;&gt;&gt;&gt;&gt;&gt; requirements and associated types you end up with types that appear to<br class="">&gt;&gt;&gt;&gt;&gt;&gt;&gt; interoperate but in fact trap at runtime unless used in exactly the<br class="">&gt;&gt;&gt;&gt;&gt;&gt;&gt; right way.<br class="">&gt;&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt;&gt; Trap at runtime?&nbsp; How so?&nbsp; Generalized existentials should still be<br class="">&gt;&gt;&gt;&gt;&gt;&gt; type-safe.<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt; There are two choices when you erase static type relationships:<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt; 1. Acheive type-safety by trapping at runtime<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt; FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt; 2. Don't expose protocol requirements that involve these relationships,<br class="">&gt;&gt;&gt;&gt;&gt; which would prevent the code above from compiling and prevent<br class="">&gt;&gt;&gt;&gt;&gt; FloatingPoint from conforming to itself.<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt;&gt; Or are you talking about the hypothetical types / behaviors people<br class="">&gt;&gt;&gt;&gt;&gt;&gt; think they want when they don’t fully understand what is happening...<br class="">&gt;&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt;&gt; I don't know what you mean here.&nbsp; I think generalized existentials will<br class="">&gt;&gt;&gt;&gt;&gt; be nice to have, but I think most people will want them to do something<br class="">&gt;&gt;&gt;&gt;&gt; they can't possibly do.<br class="">&gt;&gt;&gt;&gt;<br class="">&gt;&gt;&gt;&gt; Exactly.&nbsp; What I meant is that people think they want that expression<br class="">&gt;&gt;&gt;&gt; to compile because they don’t understand that the only thing it can do<br class="">&gt;&gt;&gt;&gt; is trap.&nbsp; I said “hypothetical” because producing a compile time error<br class="">&gt;&gt;&gt;&gt; rather than a runtime trap is the only sane thing to do.&nbsp; Your comment<br class="">&gt;&gt;&gt;&gt; surprised me because I can’t imagine we would move forward in Swift<br class="">&gt;&gt;&gt;&gt; with the approach of trapping.<br class="">&gt;&gt;&gt;<br class="">&gt;&gt;&gt; I would very much like to be able to create instances of “Collection<br class="">&gt;&gt;&gt; where Element == Int” so we can throw away the wrappers in the stdlib.<br class="">&gt;&gt;&gt; That will require some type mismatches to be caught at runtime via<br class="">&gt;&gt;&gt; trapping.<br class="">&gt;&gt;<br class="">&gt;&gt; For invalid index because the existential accepts a type erased index?<br class="">&gt;<br class="">&gt; Exactly.<br class="">&gt;<br class="">&gt;&gt; How do you decide where to draw the line here?&nbsp; It feels like a very<br class="">&gt;&gt; slippery slope for a language where safety is a stated priority to<br class="">&gt;&gt; start adopting a strategy of runtime trapping for something as<br class="">&gt;&gt; fundamental as how you expose members on an existential.<br class="">&gt;<br class="">&gt; If you don't do this, the alternative is that “Collection where Element<br class="">&gt; == Int” does not conform to Collection.&nbsp; That's weird and not very<br class="">&gt; useful.&nbsp; You could expose all the methods that were on protocol<br class="">&gt; extensions of Collection on this existential, unless they used<br class="">&gt; associated types other than the element type.&nbsp; But you couldn't pass the<br class="">&gt; existential to a generic function like<br class="">&gt;<br class="">&gt;&nbsp; &nbsp;func scrambled&lt;C: Collection&gt;(_ c: C) -&gt; [C.Element]<br class=""><br class=""></div></div>I don’t understand. Why couldn’t an existential be passed to that function?<br class=""><br class="">-Thorsten<br class=""><div class="HOEnZb"><div class="h5"><br class=""><br class=""><br class="">&gt;<br class="">&gt;&gt; IMO you should *have* to introduce unsafe behavior like that manually.<br class="">&gt;<br class="">&gt;&nbsp; Collection where Element == Int &amp; Index == *<br class="">&gt;<br class="">&gt; ?<br class="">&gt;<br class="">&gt;&gt; Collection indices are already something that isn’t fully statically<br class="">&gt;&gt; safe so I understand why you might want to allow this.<br class="">&gt;<br class="">&gt; By the same measure, so are Ints :-)<br class="">&gt;<br class="">&gt; The fact that a type's methods have preconditions does *not* make it<br class="">&gt; “statically unsafe.”<br class="">&gt;<br class="">&gt;&gt; But I don’t think having the language's existentials do this<br class="">&gt;&gt; automatically is the right approach.&nbsp; Maybe there is another approach<br class="">&gt;&gt; that could be used in targeted use cases where the less safe behavior<br class="">&gt;&gt; makes sense and is carefully designed.<br class="">&gt;<br class="">&gt; Whether it makes sense or not really depends on the use-cases.&nbsp; There's<br class="">&gt; little point in generalizing existentials if the result isn't very useful.<br class="">&gt; The way to find out is to take a look at the examples we currently have<br class="">&gt; of protocols with associated types or Self requirements and consider<br class="">&gt; what you'd be able to do with their existentials if type relationships<br class="">&gt; couldn't be erased.<br class="">&gt;<br class="">&gt; We have known use-cases, currently emulated in the standard library, for<br class="">&gt; existentials with erased type relationships.&nbsp; *If* these represent the<br class="">&gt; predominant use cases for something like generalized existentials, it<br class="">&gt; seems to me that the language feature should support that.&nbsp; Note: I have<br class="">&gt; not seen anyone build an emulation of the other kind of generalized<br class="">&gt; existential.&nbsp; My theory: there's a good reason for that :-).<br class="">&gt;<br class="">&gt; --<br class="">&gt; Dave<br class="">&gt; _______________________________________________<br class="">&gt; swift-evolution mailing list<br class="">&gt;<span class="Apple-converted-space">&nbsp;</span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">&gt;<span class="Apple-converted-space">&nbsp;</span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></blockquote></div><br class=""></div></blockquote></body></html>