<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 1:36 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" 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="">(inline)<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 27, 2016 at 10:09 AM, Thorsten Seitz<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:tseitz42@icloud.com" target="_blank" class="">tseitz42@icloud.com</a>></span><span class="Apple-converted-space"> </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 style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">Am 27.05.2016 um 18:36 schrieb Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>>:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><div class="">I think the parentheses are the fundamental aspect of the suggestion :).</div><div class=""><br class=""></div><div class="">Let me turn the question around. If tuples were declared like this:</div><div class=""><br class=""></div><div class="">let myTuple : Int, String, Bool = (10, "hello", false)</div><div class=""><br class=""></div><div class="">would the type be more or less readable? I find it a lot more difficult to immediately parse than:</div><div class=""><br class=""></div><div class="">let myTuple : (Int, String, Bool) = (10, "hello", false)</div><div class=""><br class=""></div><div class="">At the same time, nobody's complained about tuple type parentheses getting in the way. </div></div></div></blockquote><div class=""><br class=""></div></span>Parentheses are the hallmark of tuples, so its natural to expect them around the tuple type as well :-)</div></div></blockquote><div class=""><br class=""></div><div class="">But this is a circular definition. Why can't parentheses be the hallmark of structural types, not just tuples? After all, one of the big complaints against the Any<> and protocol<> syntaxes has been that angle brackets belong to generics already.</div></div></div></div></div></blockquote><div><br class=""></div><div>They are not a hallmark of function types. We write `(Int) -> (Int) -> (Int) -> Int`, not `((Int) -> (Int) -> (Int) -> Int)`.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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="gmail_extra"><div class="gmail_quote"><div class=""> </div><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 style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">We're trying to establish a syntax that will hopefully be used for things significantly more complicated than tuple definitions, which are just a list of types. I think readability is a major concern. Typealiases should be supported, but they shouldn't be required to make the feature useable.</div><div class=""><br class=""></div><div class="">Finally, wouldn't we need some delimiter for nested existential definitions anyways? Now you have the confusing situation where the outside definition has no delimiters, but the inside ones do:</div></div></div></blockquote><div class=""><br class=""></div></span>Why is this confusing? The expression `2 * (3 + 1)` also has parentheses only around the part which needs them. </div><div class="">Probably no one would require having to write `(2 * (3 + 1))` for consistency.</div></div></blockquote><div class=""><br class=""></div><div class="">You can make the same argument about tuples.</div><div class=""> </div><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 style="word-wrap: break-word;" class=""><div class=""></div><div class=""> </div><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">// Why does the inner existential look fundamentally different than the outer one?</div><div class="">// Not to mention, visually parsing the boundaries of this type when you look at it in a function signature</div><div class="">let x : Protocol1, Protocol2, (Protocol 3 where .Foo == Int) where Protocol2.Bar : Baz</div></div></div></blockquote><div class=""><br class=""></div></span><div class=""><div class="">Using `&` instead of `,` will make it look better, too, IMHO:</div><div class=""><br class=""></div><div class="">let x: Protocol1 & Protocol2 & (Protocol3 where .Foo == Int) where Protocol2.Bar: Baz</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I agree that '&' is better - my mistake. I still submit my concerns about legibility.</div><div class=""> </div><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 style="word-wrap: break-word;" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">or better (removing the asymmetry):</div><div class=""><br class=""></div><div class="">let x: Protocol1 & (Protocol2 where .Bar : Baz) & (Protocol3 where .Foo == Int)</div><div class=""><br class=""></div><div class="">or putting all constraints in the where clause for the whole expression:</div><div class=""><br class=""></div><div class="">let x: Protocol1 & Protocol2 & Protocol3 where Protocol2.Bar: Baz, Protocol3.Foo == Int</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I would much rather have parentheses enclosing the outside type than force people to structure their requirements a certain way.</div></div></div></div></div></blockquote><br class=""></div><div>That’s not a fair statement. To be clear, nobody is asking to have anyone *forced* to do anything here except you. We want parentheses to be *optional* (use them if you find them an aid to clarity and readability). You’re arguing that the language *forces* all of us to use parentheses for *every* existential type *everywhere*.</div><div><br class=""></div><div>I have no objection to you *preferring* the style of always using the outer parentheses. The community might even come to the conclusion that this is the best practice. But I don’t see a good reason to *require* them in the formal syntax of the language.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" 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="gmail_extra"><div class="gmail_quote"><div class=""> </div><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 style="word-wrap: break-word;" class=""><div class=""><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="">-Thorsten</div></div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">I hope that explains my reasoning.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 27, 2016, at 9:28 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>> wrote:</div><br class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class=""><br class="">Sent from my iPad</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class="">On May 27, 2016, at 11:18 AM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="">Here's a strawman idea.<div class=""><br class=""></div><div class="">What if we go with '&' and 'where', but we enclose the whole thing in parentheses?</div><div class=""><br class=""></div><div class="">(class & Protocol1 & Protocol2 where .Foo == Int, .Bar : Baz)</div><div class=""><br class=""></div><div class="">There are a couple of reasons I propose this syntax:</div><div class=""><br class=""></div><div class="">- It makes it very clear where the definition of the type begins and ends. I understand people really despise angle brackets, but I really want some way to visually delineate the boundaries of the type. Plus, I imagine it makes syntax a little easier to parse and preemptively forbids some ambiguities.</div><div class=""><br class=""></div><div class="">- It's a structural, not nominal, type, like a tuple, so it uses parens as well. This reserves "<" and ">" for generic types.</div><div class=""><br class=""></div><div class="">- The '&' is easily understood - "Protocol1" *and* "Protocol2". It's also a signal that order doesn't matter - just like how order matters with things that use commas, like argument lists, tuples, and array members, order doesn't generally matter with bitwise or logical 'and' operators.</div><div class=""><br class=""></div><div class="">- If we ever decide to have union types, we have a very elegant third form of nominal type syntax that naturally falls out: (MyClass1 | MyClass2 | MyClass3).</div><div class=""><br class=""></div><div class="">Thoughts?</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class=""></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">Generally in favor. But I would not require the parentheses. I believe they would be allowed optionally automatically, just as (Int) is the same as Int (because single element tuples don't exist and the underlying type is used directly instead). It seems better to leave parentheses up to a matter of style.</span><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 27, 2016, at 9:07 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 27.05.2016 um 16:54 schrieb Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>>:</div><br class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class=""><br class="">On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class="">Personally I think `&` is more lightweight (and it is established in other languages like Ceylon and Typescript) and `where` is more expressive (and established in Swift for introducing constraints), so I would stay with these.</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">I agree. If we can make `&` with `where` work syntactically it would be nice to go in this lighter weight direction. If we decide to do that the question then becomes what to do with `protocol`. Would it be feasible to replace it with `&` in Swift 3 if we decide on that direction?</div></div></blockquote><div class=""><br class=""></div>Yep. `protocol` should be replaced with `&` in that case.</div><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class=""><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">-Thorsten<br class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 27.05.2016 um 14:34 schrieb Vladimir.S <<a href="mailto:svabox@gmail.com" target="_blank" class="">svabox@gmail.com</a>>:</div><br class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">Btw, in case we have `where` keyword in syntax related to types/protocols (when defining constrains. and not some symbol like '>>'.. don't know, for example), why we can't have 'and' keyword also when discuss the syntax of type/protocol conjunction?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">I.e.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">let x: P and Q</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">let x: P and Q where P.T == Q.T</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">let x: P and Q and R</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">or, for consistency, as I understand it, we should have</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">let x: P & Q >> P.T == Q.T</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">On 27.05.2016 11:55, Thorsten Seitz via swift-evolution wrote:</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">We could just write<br class=""><br class="">let x: P & Q<br class="">instead of<br class="">let x: Any<P, Q><br class=""><br class="">let x: Collection where .Element: P<br class="">instead of<br class="">let x: Any<Collection where .Element: P><br class=""><br class="">let x: P & Q where P.T == Q.T<br class="">instead of<br class="">let x: Any<P, Q where P.T == Q.T><br class=""><br class="">let x: P & Q & R<br class="">instead of<br class="">let x: Any<P, Q, R><br class=""><br class="">let x: Collection<br class="">instead of<br class="">let x: Any<Collection><br class=""><br class=""><br class="">This would avoid the confusion of Any<T1, T2> being something completely<br class="">different than a generic type (i.e. order of T1, T2 does not matter whereas<br class="">for generic types it is essential).<br class=""><br class=""><br class="">-Thorsten<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">Am 26.05.2016 um 20:11 schrieb Adrian Zubarev via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>>>:<br class=""><br class="">Something like |type<…>| was considered at the very start of the whole<br class="">discussion (in this thread<br class=""><<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html</a>>),<br class="">but it does not solve the meaning of an existential type and also might<br class="">lead to even more confusion.<br class=""><br class="">From my perspective I wouldn’t use parentheses here because it looks more<br class="">like an init without any label |Type.init(…)| or |Type(…)|. I could live<br class="">with |Any[…]| but this doesn’t look shiny and Swifty to me. Thats only my<br class="">personal view. ;)<br class=""><br class=""><br class=""><br class=""><br class="">--<br class="">Adrian Zubarev<br class="">Sent with Airmail<br class=""><br class="">Am 26. Mai 2016 bei 19:48:04, Vladimir.S via swift-evolution<br class="">(<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>>) schrieb:<br class=""><br class=""><blockquote type="cite" class="">Don't think {} is better here, as they also have "established meaning in<br class="">Swift today".<br class=""><br class="">How about just Type(P1 & P2 | P3) - as IMO we can think of such<br class="">construction as "creation" of new type and `P1 & P2 | P3` could be treated<br class="">as parameters to initializer.<br class=""><br class="">func f(t: Type(P1 & P2 | P3)) {..}<br class=""><br class=""><br class="">On 26.05.2016 20:32, L. Mihalkovic via swift-evolution wrote:<br class="">> How about something like Type{P1 & P2 | P3} the point being that "<...>" has an established meaning in Swift today which is not what is expressed in the "<P1,P2,P3>" contained inside Any<P1, P2,P3>.<br class="">><br class="">>> On May 26, 2016, at 7:11 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class="">>><br class="">>><br class="">>>> on Thu May 26 2016, Adrian Zubarev <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class="">>>><br class="">>>> There is great feedback going on here. I'd like to consider a few things here:<br class="">>>><br class="">>>> * What if we name the whole thing `Existential<>` to sort out all<br class="">>>> confusion?<br class="">>><br class="">>> Some of us believe that “existential” is way too theoretical a word to<br class="">>> force into the official lexicon of Swift. I think “Any<...>” is much<br class="">>> more conceptually accessible.<br class="">>><br class="">>>><br class="">>>> This would allow `typealias Any = Existential<>`. * Should<br class="">>>> `protocol A: Any<class>` replace `protocol A: class`? Or at least<br class="">>>> deprecate it. * Do we need `typealias AnyClass = Any<class>` or do we<br class="">>>> want to use any class requirement existential directly? If second, we<br class="">>>> will need to allow direct existential usage on protocols (right now we<br class="">>>> only can use typealiases as a worksround).<br class="">>><br class="">>> --<br class="">>> Dave<br class="">>><br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>><span class=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>><br class="">>><span class=""> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">><span class=""> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>><br class="">><span class=""> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" 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" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class=""> </span><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>