<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Modules do more than that. For instance, if two imported modules provide a type with the same name, you can distinguish (name-spacing) them by using ModuleA.Thing vs ModuleB.Thing. <div><br></div><div>In regards of Modules being intended to be shipped separately, that is incorrect. You might be thinking of packages. </div><div><br></div><div>In Swift 4, a package can contain multiple binaries, including executables and libraries. These, can be composed of one or many modules. </div><div><br></div><div>Swift Package Manager handles this really well, and allows to organize the code separating it by features or concerns. </div><div><br></div><div>I understand Xcode does not have very good support for modules yet, other than importing frameworks. But it is my understanding this is something the new Xcode’s build system will solve, hopefully by Xcode 10. </div><div><br></div><div>I’m not against nesting protocol definitions, I can see a few cases where it could be nice to have them. But in regards of namespacing, I think using nested types is the wrong direction. </div><div><br></div><div><div>Thank you,<br><div id="AppleMailSignature"><div style="direction: inherit;">Eneko Alonso </div></div><div><br>On Dec 29, 2017, at 19:00, Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com">kelvin13ma@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Modules in Swift are really designed for code that is intended to be shipped separately. as Jon found out modules are pretty heavyweight and introduce a lot of unwanted abstraction and complexity when all you want to do is write things in a namespace. (Also if you forgot, importing a module in Swift dumps all of its symbols into the global namespace so <span style="font-family:monospace,monospace">Module.Thing</span> is really meaningless.) sometimes this is a good thing because no one wants to be writing <span style="font-family:monospace,monospace">Glibc.fopen</span> over and over especially when you have to <span style="font-family:monospace,monospace">#if #endif</span> it out every time with <span style="font-family:monospace,monospace">Darwin.fopen</span> if you want your library to run on OSX but this feature also makes modules ineffective as a namespacing scheme. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 29, 2017 at 8:35 PM, Eneko Alonso <span dir="ltr"><<a href="mailto:eneko.alonso@gmail.com" target="_blank">eneko.alonso@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div dir="ltr"><font color="#000000"><span style="background-color:rgba(255,255,255,0)">…all i wanted to do was write Thing:Namespace.Protocol</span></font></div></blockquote><div><br></div></span><div>Have you thought of using Swift modules for that? Maybe that would be a better approach than trying to name-space within a module?</div><div><br></div>Regards,<br><div><div style="direction:inherit">Eneko Alonso</div></div><div><div class="h5"><div><br>On Dec 29, 2017, at 16:51, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">…all i wanted to do was write Thing:Namespace.Protocol<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 28, 2017 at 4:43 PM, Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 class="m_7184833657857587800m_8035418850722538819bloop_markdown"><p>Well again I don’t think we should disallow capturing the outer generic type parameter just because you cannot use the protocol inside the outer type atm., you still can add a type-eraser. To be honest such usage of the existential is not even a requirement for the outer type. On there other hand we might want to set the default for the associated type like I showed in my previous message. The nested protocol could serve a completely different purpose. Furthermore I still think that <code>Generic<A>.P</code> and <code>Generic<B>.P</code> should be distinct protocols just like nested generic and non-generic types are within an outer generic type. Sure there could be other problems with ambiguity if you think of something like <code>GenericViewController<T>.Deleg<wbr>ate</code>, but the disambiguation when conforming to such protocols requires a different solution and is a well known limitation today. </p>
<p>That said you won’t design such nested types anyways if you know the existing language limitation.
I’d say let’s keep it simple in theory and just align the nesting behaviour. </p>
<p>About existentials:</p>
<p>For that scenario I can only speak for myself. I wouldn’t want to allow directly the <code>where</code> clause existentials like this. It is far better and more readable when we force the <code>where</code> clause on typealiases instead. We could lift that restriction later if we’d like to, but not the other way around. I think it’s okay if we start with a small restriction first and see if it adopts well (this is MHO), because this way it shouldn’t harm anybody.</p>
<p></p></div><div><div class="m_7184833657857587800h5"><div class="m_7184833657857587800m_8035418850722538819bloop_original_html"><div id="m_7184833657857587800m_8035418850722538819bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="m_7184833657857587800m_8035418850722538819bloop_sign_1514496023296505088" class="m_7184833657857587800m_8035418850722538819bloop_sign"></div> <br><p class="m_7184833657857587800m_8035418850722538819airmail_on">Am 28. Dezember 2017 um 21:51:29, Karl Wagner (<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="m_7184833657857587800m_8035418850722538819clean_bq"><span><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div>
<br>
<div><br>
<blockquote type="cite">
<div>On 28. Dec 2017, at 12:34, Adrian Zubarev
<<a href="mailto:adrian.zubarev@devandartist.com" target="_blank">adrian.zubarev@devandartist.c<wbr>om</a>> wrote:</div>
<br class="m_7184833657857587800m_8035418850722538819Apple-interchange-newline">
<div>
<div class="m_7184833657857587800m_8035418850722538819bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)">
<p style="margin:15px 0px">I
disagree with some of your points. Do begin with, I don’t think we
should disallow capturing the generic type parameter, because I
think there might be a good way to prevent parameterization of
nested protocols.</p>
<p style="margin:15px 0px">To me this only feels like a
natural consequence of nesting protocols anyways. To achieve this
we have to provide an explicit associated type which will have a
default type that refers to the captured outer generic type
parameter. At this point we discover another issue that we cannot
disambiguate generic type parameter like associated types yet and
would be forced to name the associated type of the protocol
differently.</p>
<pre style="margin:15px 0px;font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_7184833657857587800m_8035418850722538819swift" style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">struct Generic<T> {
protocol P {
associatedtype R = T
func f() -> R
}
}
</code></pre>
<p style="margin:15px 0px">As you can see I didn’t
include the variable in this example, because existential are
orthogonal this issue. David Hart and I still want to write a
proposal to allow the<span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal">where</code><span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span>clause on typealiases - maybe
after the forum officially launches.</p>
<p style="margin:15px 0px">Above I said that there is an
issue and provided an example that would solve that issue with
todays syntax, but I’d rather expand this idea. Consider this
syntax of a generic type and a protocol with an associated
type.</p>
<pre style="margin:15px 0px;font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_7184833657857587800m_8035418850722538819swift" style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">protocol Proto {
associatedtype Element
}
Proto.Element // This is an error like this, but it's still allowed in a generic context
func function<P : Proto>(_: P) where P.Element == Int {}
protocol OtherProto : Proto where Element == Int {}
struct Test<Element> {}
extension Test where Element == Int {}
Test.Element // Can/should we allow this?
</code></pre>
<p style="margin:15px 0px">If we could allow this in
Swift then the above example with the nested protocol could be
disambiguated nicely.</p>
<pre style="margin:15px 0px;font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_7184833657857587800m_8035418850722538819swift" style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">struct Generic<T> {
protocol P {
associatedtype T = Generic.T
func f() -> T
}
}
</code></pre>
<p style="margin:15px 0px">Remember that<span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal">Generic.T</code><span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span>is only the default
for<span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal">P.T</code><span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span>if you don’t set it yourself
but when you conform or use that that protocol (in a generic
context) you can still set it differntly.</p>
<p style="margin:15px 0px">This consequence disallows
protocol parameterization through nesting in a generic types, but
still behaves very similar to nested generic types:</p>
<pre style="margin:15px 0px;font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_7184833657857587800m_8035418850722538819swift" style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">struct Test<T> {
struct NonGeneric {
var t: T
}
struct Generic<R> {
var t: T
var r: R
}
}
_ = Test<String>.NonGeneric(t: "😎")
_ = Test<String>.Generic<Int>(t: "🤓", r: 42)
</code></pre>
<p style="margin:15px 0px">——</p>
<div><br></div>
</div>
</div>
</blockquote>
<div><br></div>
Yeah, that’s all well and good. I don’t think we should
parameterise protocols either; it feels like Swift hasn’t been
designed with those in mind, and that’s fine. You would get in to
all kinds of horrible conflicts if you tried to conform to both
Generic<Int>.P and Generic<String>.P, because most
functions would have the same signature but possibly very different
implementations. You would likely end up having to separate the
conformances by using a wrapper struct — in which case, why not
just make them the same protocol and have the existing
duplicate-conformance rules take care of it?</div>
<div><br></div>
<div>An earlier version of the proposal included something like you
describe. Basically, Generic<Int>.P and
Generic<String>.P would be the same protocol. They would have
an associated type to represent the parameter from
Generic<T>, and within Generic<T>, all references to P
would be implicitly constrained so that P.T == Self.T. You would
write conformances to “Generic.P” with a constraint for T, as you
do today.</div>
<div>
<blockquote type="cite">
<div>
<div class="m_7184833657857587800m_8035418850722538819bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)">
<p style="margin:15px 0px">And for the existential
variable inside<span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal">Genric</code><span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span>it really should be something
like this (when the where clause is allowed and if we can refer
differently to generic type parameters as well):</p>
<pre style="margin:15px 0px;font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal"><code class="m_7184833657857587800m_8035418850722538819swift" style="font-family:Menlo,Consolas,"Liberation Mono",Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">struct Generic<T> {
…
typealias PConstrainedByT = P where T == Self.T
var object: PConstrainedByT
}
</code></pre>
<div style="margin:15px 0px"><br class="m_7184833657857587800m_8035418850722538819webkit-block-placeholder"></div>
</div>
</div>
</blockquote>
<div>If we have that ability, then we can totally do capturing.
Forgive me, but I understand that as pretty-much the same as
generalised existentials (without local type binding).</div>
<div>If I can write the type of object as an existential of
(generic protocol + constraints) via a typealias, then surely I
must also be able to do it directly? So I could also write:</div>
<div><br></div>
<div>struct Generic<T> {</div>
<div> var object: P where T == Self.T</div>
<div>}</div>
<div><br></div>
<div>Anyway, I thought that was not on the table, and in any case
I’m convinced that it should be a separate proposal. This gets to
the heart of the interaction between generic types and protocols,
and we all know it’s not always a smooth transition (hello
AnyCollection, AnyHashable, etc...). We can cover the common cases
(i.e. the Apple frameworks) without requiring capturing -
especially since it’s apparently not too difficult to implement -
and build from there.</div>
<div><br></div>
- Karl</div>
<div><br>
<blockquote type="cite">
<div>
<div class="m_7184833657857587800m_8035418850722538819bloop_original_html" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)">
<div id="m_7184833657857587800m_8035418850722538819bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px"><br></div>
<br>
<div id="m_7184833657857587800m_8035418850722538819bloop_sign_1514458702433282816" class="m_7184833657857587800m_8035418850722538819bloop_sign"></div>
<br>
<p class="m_7184833657857587800m_8035418850722538819airmail_on" style="margin:15px 0px">Am 27. Dezember
2017 um 19:53:36, Karl Wagner via swift-evolution (<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a>) schrieb:</p>
<blockquote type="cite" class="m_7184833657857587800m_8035418850722538819clean_bq" style="margin:15px 0px">
<div style="word-wrap:break-word;line-break:after-white-space">
<div></div>
<div><span style="margin-top:0px;margin-bottom:0px">Yeah I wrote that proposal. I eventually stripped it down
to just disallow all capturing, but it was still not selected by
the core team for review ¯\_(ツ)_/¯</span>
<div><span style="margin-top:0px;margin-bottom:0px"><br></span></div>
<div><span style="margin-top:0px;margin-bottom:0px">As for capturing semantics, once you start working through
use-cases, it’s becomes clear that it's going to require
generalised existentials. Otherwise, how would you use a
Generic<T>.P?</span></div>
<div><span style="margin-top:0px;margin-bottom:0px"><br></span></div>
<div><span style="margin-top:0px;margin-bottom:0px">struct Generic<T> {</span></div>
<div><span style="margin-top:0px;margin-bottom:0px"> protocol P { func f() -> T }</span></div>
<div><span style="margin-top:0px;margin-bottom:0px"><br></span></div>
<div><span style="margin-top:0px;margin-bottom:0px"> var object: P // uh-oh! ‘Generic protocol
can only be used as a generic parameter constraint'</span></div>
<div><span style="margin-top:0px;margin-bottom:0px">}</span></div>
<div><span style="margin-top:0px;margin-bottom:0px"><br></span></div>
<div><span style="margin-top:0px;margin-bottom:0px">So, you would need to add a generic parameter to
actually<span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span><i>use</i><span class="m_7184833657857587800m_8035418850722538819Apple-converted-space"> </span>P from
within Generic<T>, which of course limits you to a single
concrete type of P:</span></div>
<div><br></div>
<div>struct Generic<T, TypeOfP> where TypeOfP:
Self.P { // Could this even work? What if P
captures TypeOfP?</div>
<div> protocol P { /* … */ }</div>
<div> var object: TypeOfP</div>
<div>}</div>
<div><br></div>
<div>Which is just yucky.</div>
<div><br></div>
<div>Ideally, the type of ‘object’ should be ‘Any<P
where P.T == T>’, to express that it can be any conforming type
with the appropriate constraints. You wouldn’t need to write that
all out; we could infer that capturing is equivalent to a same-type
constraint (or perhaps one of these “generalised supertype
constraints” that were pitched recently). But we can’t express
those kinds of existentials everywhere in the type-system today, so
most examples of capturing fall down pretty quickly.</div>
<div><br></div>
<div>- Karl<br>
<div><br>
<blockquote type="cite" style="margin:15px 0px">
<div style="margin-top:0px">On 25. Dec 2017, at 03:56,
Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a>>
wrote:</div>
<br class="m_7184833657857587800m_8035418850722538819Apple-interchange-newline">
<div style="margin-bottom:0px">
<div>There was a proposal to allow protocols to be nested
inside types at one point but it didn’t move forward.<br>
<br>
Basically, if the outer type is a non-generic class, struct or
enum, there’s no conceptual difficulty at all.<br>
<br>
If the outer type is a generic type or another protocol, you have a
problem where the inner protocol can reference generic parameters
or associated types of the outer type. This would either have to be
banned, or we would need to come up with coherent semantics for
it:<br>
<br>
struct Generic<T> {<br>
protocol P {<br>
func f() -> T<br>
}<br>
}<br>
<br>
struct Conforms : Generic<Int>.P {<br>
func f() -> Int { … } // Like this?<br>
}<br>
<br>
let c = Conforms()<br>
c is Generic<String>.P // is this false? Ie, are
Generic<Int>.P and Generic<String>.P different
protocols?<br>
<br>
Slava<br>
<br>
<blockquote type="cite" style="margin:15px 0px">On Dec
24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none;margin-top:0px" target="_blank">swift-evolution@swift.org</a>>
wrote:<br>
<br>
is there a reason why it’s not allowed to nest a protocol
declaration inside another type?<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">
swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br style="margin-bottom:0px"></blockquote>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">
swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div>
</div>
</blockquote>
</div>
<br></div>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div>
</div>
</blockquote>
</div>
<div class="m_7184833657857587800m_8035418850722538819bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)">
</div>
</div>
</blockquote>
</div>
<br>
</div></div></span></blockquote></div><div class="m_7184833657857587800m_8035418850722538819bloop_markdown"><p></p></div></div></div></div><br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div>
</div></blockquote></div></div></body></html>