<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 27, 2016, at 6:02 AM, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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">On May 26, 2016, at 10:56 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div id="bloop_customfont" class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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; margin: 0px;"><div class=""><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: 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;"><div dir="auto" class="" style="zoom: 1;"><div class="bloop_container"><div class="bloop_frame"><blockquote type="cite" class="" style="font-family: 'helvetica Neue', helvetica;"><div dir="ltr" class="">I alway enjoy hearing your ideas.<div class=""><br class=""></div><div class="">This is quite interesting. It's basically a way to define an ad-hoc interface that a type doesn't need to explicitly declare it conforms to. I know Golang works similarly; if a Go type implements all the requirements of an interface it conforms automatically.</div></div></blockquote><blockquote type="cite" class="" style="font-family: 'helvetica Neue', helvetica;"><div dir="ltr" class=""><div class=""><br class=""></div><div class="">There are positives and negatives to allowing this sort of ad-hoc interface.</div></div></blockquote><div class="" style="font-family: 'helvetica Neue', helvetica;"><br class=""></div><div class="" style="font-family: 'helvetica Neue', helvetica;">Agree. It would definitely make the language "feel" a bit more fluid. But it doesn't add any expressive power and could have undesirable consequences.</div><br class="" style="font-family: 'helvetica Neue', helvetica;"><blockquote type="cite" class="" style="font-family: 'helvetica Neue', helvetica;"><div dir="ltr" class="">This would make for a good standalone proposal -- both because it's complex enough to deserve its own discussion, and because if the community is interested someone would have to work through all the implications in order to put together a proposal. It would be quite a big change.</div></blockquote><div class="" style="font-family: 'helvetica Neue', helvetica;"><br class=""></div><div class="" style="font-family: 'helvetica Neue', helvetica;"><span class="" style="background-color: rgba(255, 255, 255, 0);">I don't see how this is different from a protocol other than the lack of requirement to declare conformance explicitly. The need to explicitly declare conformance is a design decision that I believe the core team feels pretty strongly about. </span></div><div class="" style="font-family: 'helvetica Neue', helvetica;"><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class="" style="font-family: 'helvetica Neue', helvetica;"><span class="" style="background-color: rgba(255, 255, 255, 0);">That said, it hasn't been debated by the community yet so if someone feels strongly about dropping explicit conformance declarations it might be worth pitching the idea, if for not other reason than to have a discussion about it on the lost.</span></div></div></div></div></blockquote></div><p class="">I don’t see any desire to follow Go’s path here and drop explicit conformance in any way.</p><p class="">Basically such `existential` mechanism could express more than `Any<…>` could. That said I do feel that this "could“ have some potential to exist alongside `Any<…>`.</p><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div>Anything “more” it could express would be specific member requirements, which would make it in some sense ad-hoc protocol. I would rather see one mechanism for defining member requirements. We already have that and it is called a protocol.</div><div class=""><br class=""></div><div class="">The reason types won’t need to declare explicit conformance to an `Any` is that the requirements of the `Any` are composed of an optional supertype as well zero or more protocol and associated type constraints. The “conformance" of a type to the `Any` is defined by its conformance to the protocols that the `Any` is composed of. </div><div class=""><br class=""></div><div class="">If you want to introduce new requirements the right way to do it is to declare an additional protocol and add it to the list of protocol constraints in the `Any`.<br class=""><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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; margin: 0px;"><p class="">From my understanding of this whole existential type thing is that it can be used both ways, explicitly and implicitly. As said before we only discussed the explicit existential types.</p><p class=""><br class=""></p><p class="">Just another pseudo example:</p><p class="">```swift</p><p class="">// this could also replace typealiases for (generic) existentials</p><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div>I gave some consideration to scoped syntax like this a few days ago. The problem with it is that `Any` is a structural type defined by the constraints and this makes it look like a nominal type. </div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 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="">I am not sure I follow you.. If Any is a structural type, then case closed, it is instantiate-able and carry all the normal behavior of all other structural types. Or is it a wolf in sheep's clothing that is actually neither a wolf, nor a sheep?</div></div></blockquote><div><br class=""></div>It is defined by the structure of the constraints, not the structure of the data. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 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="">This is ultimately coming back to my earlier question of how does one differentiate between X<...> and Y<...>? </div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 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="">Should we read the angle brackets first and reach the logical (but wrong) conclusion that X and Y will essentially behave in a similar fashion, or should we read the names first and remember that we have to go to two different pages of the swift programmer's guide to make sense of what follows?</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 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="">As was previously said with great eloquence (i believe by Joe Groff), Any<> is something only a compiler loves... I would like it if we found something both the swift compiler and the swift programmer could love.</div></div></blockquote><div><br class=""></div><div>It isn’t entirely clear to me what you’re arguing for here. It *seems* like maybe your advocating for the `&` syntax (or similar) to make a stronger differentiation from generic types. That makes sense.</div><div><br class=""></div><div>The point I was making is that any names we give to an existential type are *aliases* for it. The name doesn’t matter as far as the type system is concerned. The syntax Adrian posted makes it *look* like the name actually matters to the type system IMO and introduces potential for confusion because of that.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 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: 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 class=""><br class=""></div><div class="">If you define two “existential” types with the exact same constraints under different names, what happens? They should be identical to other any equivalent formulation and that is clear under Austin’s proposal, but because this alternative looks like a nominal type you might have the expectation that the types are independent of each other. That is why typealias is the correct solution here IMO. It is clear that the name is just an alias for a structural type.</div><div class=""><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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; margin: 0px;"><p class="">existential CrazyView {</p><p class=""> // we could introduce a way for constraints which could have a nice looking syntax</p><p class=""> // break `Any<…>` nesting and long very long composition lines of `Any<…>` </p><p class=""> constraint Any<UIScrollView, Any<UITableView, Any<UIView, ProtocolA>>></p><p class=""> constraint ProtocolA.AssociatedType == Int </p><p class=""> func crazyFunction()</p><p class="">}</p><p class=""><br class=""></p><p class="">existential AnyCollection<T> {</p><p class=""> constraint Collection</p><p class=""> constraint Collection.Element == T</p><p class="">}</p><p class="">```</p><div class="">But I don’t want to go any further if there is no need (yet).</div></div><br class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;"><div id="bloop_sign_1464293870604892928" class="bloop_sign" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;"><div class="" style="font-family: helvetica, arial; font-size: 13px;">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div><br class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;"><span class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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; float: none; display: inline !important;">_______________________________________________</span><br class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;"><span class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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; float: none; display: inline !important;">swift-evolution mailing list</span><br class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;"><a href="mailto:swift-evolution@swift.org" class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;">swift-evolution@swift.org</a><br class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: 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;">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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=""></body></html>