<div dir="ltr"><div>Thanks for all your thoughtful replies.</div><div><br></div>I&#39;m not really invested in arguing this much further, as it&#39;s mainly a stylistic thing that I could live with and also probably a hopeless battle (given how everyone else disagrees). But I would like to address a few final points.<div><br></div><div>(inline)<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 27, 2016 at 12:06 PM, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><br></span><div><br></div><div>Turning it around, we don’t have to put parentheses around function types and nobody complains about it being problematic even for higher-order functions with several steps before the final result.</div></div></div></blockquote><div><br></div><div>Function types have a very regular syntax, especially now that 0066 was accepted (which, I admit, was very controversal itself):</div><div><br></div><div>( &lt;one or more types&gt; ) -&gt; (tuple)</div><div>or</div><div>( &lt;one or more types&gt; ) -&gt; SingleTypeWithNoSpaces</div><div>or</div><div>( &lt;one or more types&gt; ) -&gt; GenericType&lt;All, Spaces, Are, Inside, The, Brackets&gt;</div><div><br></div><div>A function type is very easy to visually parse: combine the argument parens, arrow thing, and the single type that it returns. That being said, complex function types are probably the most difficult types to read in a function declaration today, even with this regular structure.</div><div><br></div><div>The proposed syntax, which allows arbitrary whitespace outside the context of a delimiter, would require the user to scan the string comprising the existential type expression for a very common sigil in order to locate the endpoint: &#39;=&#39; for variable declarations (which admittedly isn&#39;t that bad) or &#39;,&#39; for functions (which is a lot worse). Not to mention the point Joe Groff brought up about a generic function with a generic where clause returning an existential and having everything devolve into a undifferentiated soup of identifiers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>Does anyone know if users of Ceylon or other languages with the unparenthesized syntax find it problematic?  How would they feel about being required to use parentheses?</div><span class=""><div><br></div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>We&#39;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&#39;t be required to make the feature useable.</div></div></div></blockquote><div><br></div></span><div>I agree, but I don’t think they would be required to make the feature useable just because parentheses are not required.  If a developer or team thinks they are required for clarity / readability, etc they are free to use them.  This is a style issue that should be addressed by a linter, not the formal syntax of the language.</div></div></div></blockquote><div><br></div><div>It is a style issue, but so is (Int) -&gt; T versus Int -&gt; T and a lot of other language details like trailing commas in argument lists, of which the core team seems to feel pretty strongly about.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>Finally, wouldn&#39;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><br></div><div>// Why does the inner existential look fundamentally different than the outer one?</div><div>// Not to mention, visually parsing the boundaries of this type when you look at it in a function signature</div><div>let x : Protocol1, Protocol2, (Protocol 3 where .Foo == Int) where Protocol2.Bar : Baz</div></div></div></blockquote><div><br></div></span><div>Nested existentials are supported not because it would ever be a good idea to actually write them.  They are supported to allow composition of existentials:</div><div><br></div></div></div></blockquote><div><br></div><div>Perhaps then we should only allow existentials to be nested if a typealias is used. Swift is, after all, an opinionated language. If a feature is in the language, it should either be usable directly in an ergonomic way, or it shouldn&#39;t be there at all. Having a self-admittedly &quot;bad&quot; way to nest literal existential expressions just for consistency when typealiases are the preferred use case is very unlike Swift.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>typealias P3Int = Protocol 3 where .Foo == Int</div><div><div style="word-wrap:break-word"><div>let x : Protocol1, Protocol2, P3Int where Protocol2.Bar : Baz</div></div></div><div><br></div><div>If you are writing the entire type in a single location I expect the conventional style to be like this:</div><div><br></div><div><div style="word-wrap:break-word"><div>let x : Protocol1, Protocol2, Protocol 3 where Protocol2.Bar : Baz, Protocol3.Foo == Int</div></div></div><div><br></div><div>With all associated types constraints in a single `where` clause as we other places they are written in Swift.</div><div><br></div><div>Maybe I am wrong about that and a different conventional style would emerge (for example, where clauses clustered with the related protocol).  </div><div><br></div><div>But *requiring* parentheses is really orthogonal to the style issue of where and when it is considered *advisable* to use them.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Matthew</div></font></span><div><div class="h5"><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>I hope that explains my reasoning.</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div><br><div><blockquote type="cite"><div>On May 27, 2016, at 9:28 AM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt; wrote:</div><br><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"><br><br>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"><br>On May 27, 2016, at 11:18 AM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>&gt; wrote:<br><br></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"><div>Here&#39;s a strawman idea.<div><br></div><div>What if we go with &#39;&amp;&#39; and &#39;where&#39;, but we enclose the whole thing in parentheses?</div><div><br></div><div>(class &amp; Protocol1 &amp; Protocol2 where .Foo == Int, .Bar : Baz)</div><div><br></div><div>There are a couple of reasons I propose this syntax:</div><div><br></div><div>- 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><br></div><div>- It&#39;s a structural, not nominal, type, like a tuple, so it uses parens as well. This reserves &quot;&lt;&quot; and &quot;&gt;&quot; for generic types.</div><div><br></div><div>- The &#39;&amp;&#39; is easily understood - &quot;Protocol1&quot; *and* &quot;Protocol2&quot;. It&#39;s also a signal that order doesn&#39;t matter - just like how order matters with things that use commas, like argument lists, tuples, and array members, order doesn&#39;t generally matter with bitwise or logical &#39;and&#39; operators.</div><div><br></div><div>- 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><br></div><div>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"><br></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">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&#39;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"><br></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"><br><blockquote type="cite"><div><div><br></div><div>Austin</div><div><br></div><div><br><div><blockquote type="cite"><div>On May 27, 2016, at 9:07 AM, Thorsten Seitz via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>Am 27.05.2016 um 16:54 schrieb Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;:</div><br><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"><div><br>On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word">Personally I think `&amp;` 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"><br></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">I agree.  If we can make `&amp;` 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 `&amp;` in Swift 3 if we decide on that direction?</div></div></blockquote><div><br></div>Yep. `protocol` should be replaced with `&amp;` in that case.</div><div><br></div><div>-Thorsten</div><div><br></div><div><br><blockquote type="cite"><div><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"><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"><div><div style="word-wrap:break-word"><div><br></div><div>-Thorsten<br><div><br></div><div><br><div><blockquote type="cite"><div>Am 27.05.2016 um 14:34 schrieb Vladimir.S &lt;<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>&gt;:</div><br><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">Btw, in case we have `where` keyword in syntax related to types/protocols (when defining constrains. and not some symbol like &#39;&gt;&gt;&#39;.. don&#39;t know, for example), why we can&#39;t have &#39;and&#39; 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"><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">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"><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"><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">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"><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">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"><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">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"><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"><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">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"><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">let x: P &amp; Q &gt;&gt; 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"><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"><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">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"><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">We could just write<br><br>let x: P &amp; Q<br>instead of<br>let x: Any&lt;P, Q&gt;<br><br>let x: Collection where .Element: P<br>instead of<br>let x: Any&lt;Collection where .Element: P&gt;<br><br>let x: P &amp; Q where P.T == Q.T<br>instead of<br>let x: Any&lt;P, Q where P.T == Q.T&gt;<br><br>let x: P &amp; Q &amp; R<br>instead of<br>let x: Any&lt;P, Q, R&gt;<br><br>let x: Collection<br>instead of<br>let x: Any&lt;Collection&gt;<br><br><br>This would avoid the confusion of Any&lt;T1, T2&gt; being something completely<br>different than a generic type (i.e. order of T1, T2 does not matter whereas<br>for generic types it is essential).<br><br><br>-Thorsten<br><br><br><br><blockquote type="cite">Am 26.05.2016 um 20:11 schrieb Adrian Zubarev via swift-evolution<br>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;&gt;:<br><br>Something like |type&lt;…&gt;| was considered at the very start of the whole<br>discussion (in this thread<br>&lt;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html</a>&gt;),<br>but it does not solve the meaning of an existential type and also might<br>lead to even more confusion.<br><br>From my perspective I wouldn’t use parentheses here because it looks more<br>like an init without any label |Type.init(…)| or |Type(…)|. I could live<br>with |Any[…]| but this doesn’t look shiny and Swifty to me. Thats only my<br>personal view. ;)<br><br><br><br><br>--<br>Adrian Zubarev<br>Sent with Airmail<br><br>Am 26. Mai 2016 bei 19:48:04, Vladimir.S via swift-evolution<br>(<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;) schrieb:<br><br><blockquote type="cite">Don&#39;t think {} is better here, as they also have &quot;established meaning in<br>Swift today&quot;.<br><br>How about just Type(P1 &amp; P2 | P3) - as IMO we can think of such<br>construction as &quot;creation&quot; of new type and `P1 &amp; P2 | P3` could be treated<br>as parameters to initializer.<br><br>func f(t: Type(P1 &amp; P2 | P3)) {..}<br><br><br>On 26.05.2016 20:32, L. Mihalkovic via swift-evolution wrote:<br>&gt; How about something like Type{P1 &amp; P2 | P3} the point being that &quot;&lt;...&gt;&quot; has an established meaning in Swift today which is not what is expressed in the &quot;&lt;P1,P2,P3&gt;&quot; contained inside Any&lt;P1, P2,P3&gt;.<br>&gt;<br>&gt;&gt; On May 26, 2016, at 7:11 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;&gt; wrote:<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;&gt; on Thu May 26 2016, Adrian Zubarev &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; There is great feedback going on here. I&#39;d like to consider a few things here:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; * What if we name the whole thing `Existential&lt;&gt;` to sort out all<br>&gt;&gt;&gt; confusion?<br>&gt;&gt;<br>&gt;&gt; Some of us believe that “existential” is way too theoretical a word to<br>&gt;&gt; force into the official lexicon of Swift. I think “Any&lt;...&gt;” is much<br>&gt;&gt; more conceptually accessible.<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; This would allow `typealias Any = Existential&lt;&gt;`. * Should<br>&gt;&gt;&gt; `protocol A: Any&lt;class&gt;` replace `protocol A: class`? Or at least<br>&gt;&gt;&gt; deprecate it. * Do we need `typealias AnyClass = Any&lt;class&gt;` or do we<br>&gt;&gt;&gt; want to use any class requirement existential directly? If second, we<br>&gt;&gt;&gt; will need to allow direct existential usage on protocols (right now we<br>&gt;&gt;&gt; only can use typealiases as a worksround).<br>&gt;&gt;<br>&gt;&gt; --<br>&gt;&gt; Dave<br>&gt;&gt;<br>&gt;&gt; _______________________________________________<br>&gt;&gt; swift-evolution mailing list<br>&gt;&gt;<span> </span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;<br>&gt;&gt;<span> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>&gt; _______________________________________________<br>&gt; swift-evolution mailing list<br>&gt;<span> </span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;<br>&gt;<span> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>&gt;<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;<br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></blockquote><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span> </span>&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>&gt;<br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></blockquote><br><br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></blockquote></div><br></div></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></div></blockquote></div></div></blockquote></div><br></div></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div></div>