<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 Jul 5, 2016, at 2:59 PM, Brian Gesiak 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 dir="ltr" class=""><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important" class="">Sorry to resurrect such an old thread! I understand getting this in Swift 3.0 might not be realistic anymore, but this is still something I’d love to see added to Swift. Could someone advise on whether it still makes sense to spend time on this proposal? Or is this part of Swift too solidified to change at this point?</p></div></div></div></blockquote><div>It is definitely beyond Swift 3.0, but I’d love to see this happen at some point, we really need someone to drive the (surely to be contentious) design process.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style="">
<blockquote style="margin:1.2em 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none" class=""><p style="margin:0px 0px 1.2em!important" class="">How much would <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)" class="">Libc</code> include? The standard C library? POSIX?</p>
</blockquote><p style="margin:0px 0px 1.2em!important" class="">Yes, I had originally anticipated this as including <a href="https://github.com/apple/swift/blob/7b1a8dcf7fbcfd66f029cc5473edef5a08f86602/stdlib/public/Platform/glibc.modulemap.gyb#L29" class=""><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)" class="">module C</code></a> and <a href="https://github.com/apple/swift/blob/7b1a8dcf7fbcfd66f029cc5473edef5a08f86602/stdlib/public/Platform/glibc.modulemap.gyb#L141" class=""><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)" class="">module POSIX</code></a>. I see that <a href="https://github.com/apple/swift/pull/3107" class=""><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)" class="">module CUUID</code> was recently added as well</a>, but I don’t think that should be included.</p>
<blockquote style="margin:1.2em 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none" class=""><p style="margin:0px 0px 1.2em!important" class="">there are differences (minor, but still) between Glibc and Darwin. Those should be either unified (if possible) or re-arranged so that the unified library shares unified functionality and then each separate one can have its own set of caveats.</p>
</blockquote><p style="margin:0px 0px 1.2em!important" class="">I don’t think the unified <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248)" class="">import C</code> module should do anything besides obviate the need to write the following:</p><pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px" class=""><code class="language-swift hljs" style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);border-radius:3px;display:inline;background-color:rgb(248,248,248);white-space:pre;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important;display:block;overflow-x:auto;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248)">#<span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">if</span> os(<span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">Linux</span>) || os(<span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">FreeBSD</span>)
<span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">import</span> <span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">Glibc</span>
#<span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">else</span>
<span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">import</span> <span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">Darwin</span>
#endif
</code></pre><p style="margin:0px 0px 1.2em!important" class="">If people feel strongly about unifying the overlay, perhaps we should discuss that in future swift-evolution proposals.</p>
<blockquote style="margin:1.2em 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none" class=""><p style="margin:0px 0px 1.2em!important" class="">Personally, I like “import C”, but at the end of the day I’m happy to call it whatever as long as it solves the problem.</p>
</blockquote><p style="margin:0px 0px 1.2em!important" class="">I couldn’t have said it better myself!</p><p style="margin:0px 0px 1.2em!important" class="">/cc Saleem, since he may have Windows opinions.<br class=""><br class="">- Brian Gesiak</p>
<div title="MDH:U29ycnkgdG8gcmVzdXJyZWN0IHN1Y2ggYW4gb2xkIHRocmVhZCEgSSB1bmRlcnN0YW5kIFN3aWZ0
IDMuMCBtaWdodCBub3QgYmUgcmVhbGlzdGljIGFueW1vcmUsIGJ1dCB0aGlzIGlzIHN0aWxsIHNv
bWV0aGluZyBJJ2QgbG92ZSB0byBzZWUgYWRkZWQgdG8gU3dpZnQuIENvdWxkIHNvbWVvbmUgYWR2
aXNlIG9uIHdoZXRoZXIgaXQgc3RpbGwgbWFrZXMgc2Vuc2UgdG8gc3BlbmQgdGltZSBvbiB0aGlz
IHByb3Bvc2FsPyBPciBpcyB0aGlzIHBhcnQgb2YgU3dpZnQgdG9vIHNvbGlkaWZpZWQgdG8gY2hh
bmdlIGF0IHRoaXMgcG9pbnQ/PGJyPjxicj4mZ3Q7wqA8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx
Mi44cHg7Ij5Ib3cgbXVjaCB3b3VsZCBgTGliY2AgaW5jbHVkZT8gVGhlIHN0YW5kYXJkJm5ic3A7
PC9zcGFuPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6IDEyLjhweDsgYmFja2dyb3Vu
ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+Qzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOiAxMi44cHg7Ij4mbmJzcDtsaWJyYXJ5PyBQT1NJWD88L3NwYW4+PGJyPjxicj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOiAxMi44cHg7Ij5ZZXMsIEkgaGFkIG9yaWdpbmFsbHkgYW50aWNpcGF0
ZWQgdGhpcyBhcyBpbmNsdWRpbmcgW2Btb2R1bGUgQ2BdKGh0dHBzOi8vZ2l0aHViLmNvbS9hcHBs
ZS9zd2lmdC9ibG9iLzdiMWE4ZGNmN2ZiY2ZkNjZmMDI5Y2M1NDczZWRlZjVhMDhmODY2MDIvc3Rk
bGliL3B1YmxpYy9QbGF0Zm9ybS9nbGliYy5tb2R1bGVtYXAuZ3liI0wyOSkgYW5kIFtgbW9kdWxl
IFBPU0lYYF0oaHR0cHM6Ly9naXRodWIuY29tL2FwcGxlL3N3aWZ0L2Jsb2IvN2IxYThkY2Y3ZmJj
ZmQ2NmYwMjljYzU0NzNlZGVmNWEwOGY4NjYwMi9zdGRsaWIvcHVibGljL1BsYXRmb3JtL2dsaWJj
Lm1vZHVsZW1hcC5neWIjTDE0MSkuIEkgc2VlIHRoYXQgW2Btb2R1bGUgQ1VVSURgJm5ic3A7d2Fz
IHJlY2VudGx5IGFkZGVkIGFzIHdlbGw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIu
OHB4OyI+XShodHRwczovL2dpdGh1Yi5jb20vYXBwbGUvc3dpZnQvcHVsbC8zMTA3PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjhweDsiPiksIGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMg
c2hvdWxkIGJlIGluY2x1ZGVkLjxicj48YnI+Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOiAxMi44cHg7Ij50aGVyZSBhcmUgZGlmZmVyZW5jZXMgKG1pbm9yLCBidXQgc3Rp
bGwpIGJldHdlZW4gR2xpYmMgYW5kIERhcndpbi4gVGhvc2Ugc2hvdWxkIGJlIGVpdGhlciB1bmlm
aWVkIChpZiBwb3NzaWJsZSkgb3IgcmUtYXJyYW5nZWQgc28gdGhhdCB0aGUgdW5pZmllZCBsaWJy
YXJ5IHNoYXJlcyB1bmlmaWVkIGZ1bmN0aW9uYWxpdHkgYW5kIHRoZW4gZWFjaCBzZXBhcmF0ZSBv
bmUgY2FuIGhhdmUgaXRzIG93biBzZXQgb2YgY2F2ZWF0cy48L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTogMTIuOHB4OyI+PGJyPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog
MTIuOHB4OyI+SSBkb24ndCB0aGluayB0aGUgdW5pZmllZCBgaW1wb3J0IENgIG1vZHVsZSBzaG91
bGQgZG8gYW55dGhpbmcgYmVzaWRlcyBvYnZpYXRlIHRoZSBuZWVkIHRvIHdyaXRlIHRoZSBmb2xs
b3dpbmc6PGJyPjxicj5gYGBzd2lmdDxicj48L3NwYW4+PGRpdiBzdHlsZT0iZm9udC1zaXplOiAx
Mi44cHg7Ij4jaWYgb3MoTGludXgpIHx8IG9zKEZyZWVCU0QpPC9kaXY+PGRpdiBzdHlsZT0iZm9u
dC1zaXplOiAxMi44cHg7Ij48c3BhbiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IGltcG9ydDwvc3Bh
bj4mbmJzcDtHbGliYzwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTIuOHB4OyI+I2Vsc2U8
L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDEyLjhweDsiPjxzcGFuIGNsYXNzPSIiPiZuYnNw
OyAmbmJzcDsgaW1wb3J0PC9zcGFuPiZuYnNwO0RhcndpbjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt
c2l6ZTogMTIuOHB4OyI+I2VuZGlmPC9kaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuOHB4
OyI+YGBgPGJyPjxicj5JZiBwZW9wbGUgZmVlbCBzdHJvbmdseSBhYm91dCB1bmlmeWluZyB0aGUg
b3ZlcmxheSwgcGVyaGFwcyB3ZSBzaG91bGQgZGlzY3VzcyB0aGF0IGluIGZ1dHVyZSBzd2lmdC1l
dm9sdXRpb24gcHJvcG9zYWxzLjxicj48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDEyLjhweDsiPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjhweDsiPlBl
cnNvbmFsbHksIEkgbGlrZSAiPC9zcGFuPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6
IDEyLjhweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+aW1wb3J0PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjhweDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBj
bGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOiAxMi44cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NTUsIDI1NSwgMjU1KTsiPkM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuOHB4OyI+
IiwgYnV0IGF0IHRoZSBlbmQgb2YgdGhlIGRheSBJJ20gaGFwcHkgdG8gY2FsbCBpdCB3aGF0ZXZl
ciBhcyBsb25nIGFzIGl0IHNvbHZlcyB0aGUgcHJvYmxlbS48YnI+PC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEyLjhweDsiPjxicj5JIGNvdWxkbid0IGhhdmUgc2FpZCBpdCBiZXR0ZXIg
bXlzZWxmITxicj48YnI+L2NjIFNhbGVlbSwgc2luY2UgaGUgbWF5IGhhdmUgV2luZG93cyBvcGlu
aW9ucy48YnI+PC9zcGFuPjxkaXY+PGJyPi0gQnJpYW4gR2VzaWFrPGJyPjxicj48L2Rpdj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0" class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 9, 2016 at 6:35 AM, Honza Dvorsky <span dir="ltr" class=""><<a href="mailto:czechboy0@gmail.com" target="_blank" class="">czechboy0@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">A huge +1 on the proposal, I even have a code snippet to import the platform-appropriate C library. I try to write every new Swift library cross-platform-by-default now and this would definitely remove some friction. Not to mention it would future-proof many libraries which won't need to be updated when a new Swift platform is added.<div class=""><br class=""></div><div class="">Personally, I like "import C", but at the end of the day I'm happy to call it whatever as long as it solves the problem. I agree with Brian that with Swift scaling up to 4 or so platforms soon-ish, it's preferable to not put any extra burden on Swift users if there is an almost-uniform C API which can be used everywhere.</div></div><div class="HOEnZb"><div class="h5"><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Mar 9, 2016 at 2:03 AM Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></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" class=""><div class="">One of the reasons we haven't picked this <i class="">particular</i> name is if the C or C++ committees ever adopted modules. Given that they just got punted from C++17, though, maybe that shouldn't hold us back.</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Jordan</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 8, 2016, at 11:13, Brian Gesiak 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 dir="ltr" class=""><div class=""># Introduction</div><div class=""><br class=""></div><div class="">Currently, cross-platform Swift programs that rely on symbols defined in libc (`fputs`, `stderr`, etc.) must all write the same five lines of boilerplate code:</div><div class=""><br class=""></div><div class=""> #if os(Linux) || os(FreeBSD)</div><div class=""> import Glibc</div><div class=""> #else</div><div class=""> import Darwin</div><div class=""> #endif</div><div class=""><br class=""></div><div class="">Instead, I propose the following, which will work on all platforms:</div><div class=""><br class=""></div><div class=""> import Libc</div><div class=""><br class=""></div><div class=""># Motivation</div><div class=""><br class=""></div><div class="">Let's say we wanted to write a program that, on any platform, would print "Hello world!" to stderr. We'd probably come up with this:</div><div class=""><br class=""></div><div class=""> #if os(Linux) || os(FreeBSD)</div><div class=""> import Glibc</div><div class=""> #else</div><div class=""> import Darwin</div><div class=""> #endif</div><div class=""><br class=""></div><div class=""> fputs("Hello world!", stderr)</div><div class=""><br class=""></div><div class="">The first five lines of this program are necessary to import the symbols `fputs` and `stderr`. Five lines may not be much, but these come with significant drawbacks:</div><div class=""><br class=""></div><div class="">- They must be written in each source file that relies on libc, which is tedious.</div><div class="">- It is subject to frequent change. As Swift is ported to more platforms, that initial check must change to `#if os(Linux) || os(FreeBSD) || os(Windows) || os(Android)`, and so on. End users of Swift may not be actively involved in its development, and so may be surprised when the latest release suddenly necessitates more `os()` conditions.</div><div class="">- These combined force users to make a conscious decision to write cross-platform code--as opposed to simply writing Swift and have it work on other platforms seamlessly.</div><div class=""><br class=""></div><div class="">It would be preferable if people writing Swift did not need to check for the current `os()` in order to write code that works across platforms.</div><div class=""><br class=""></div><div class=""># Proposed solution</div><div class=""><br class=""></div><div class="">Instead of conditionally importing Darwin or Glibc, I propose the following:</div><div class=""><br class=""></div><div class=""> import Libc</div><div class=""><br class=""></div><div class="">This would import whichever libc implementation Swift was compiled with. For Ubuntu Linux releases, this would be Glibc. For OS X releases, this would be Darwin. For Android (coming soon in <a href="https://github.com/apple/swift/pull/1442" target="_blank" class="">https://github.com/apple/swift/pull/1442</a>), this would be Bionic.</div><div class=""><br class=""></div><div class="">This saves the end user from writing boilerplate code, and it isolates them from the rapid expansion of platforms on which Swift is able to be executed.</div><div class=""><br class=""></div><div class="">This idea is not novel: the Swift package manager already defines a "libc" package that is essentially the boilerplate `os()` check above: <a href="https://github.com/apple/swift-package-manager/blob/master/Sources/libc/libc.swift" target="_blank" class="">https://github.com/apple/swift-package-manager/blob/master/Sources/libc/libc.swift</a>.</div><div class=""><br class=""></div><div class="">However, rather than determining which libc implementation to use at runtime (like SwiftPM does above), I propose we allow the Swift stdlib to be compiled with any arbitrary implementation of libc.</div><div class=""><br class=""></div><div class=""># Detailed design</div><div class=""><br class=""></div><div class="">It's my understanding that the majority of this change would take place in the Swift build scripts and CMake modules. Similar to how those scripts export a module named "Glibc" on Linux (see stdlib/public/core/Glibc), this proposal could be implementing by exporting a "Libc" on all platforms.</div><div class=""><br class=""></div><div class="">This would also be accompanied by a change to the Swift 3 migrator that could automatically convert conditional imports of Darwin/Glibc to the new `import Libc`.</div><div class=""><br class=""></div><div class="">We must also devise a strategy for the transient rollout period, when Swift defines a Libc module, but we don't have an OS X SDK that uses that name in the bundled module.map. We can add a compiler hack for that, to transparently translate the name.</div><div class=""><br class=""></div><div class=""># Alternatives considered<br class=""><br class="">I believe there are two contentious points to this proposal: <br class=""><br class="">1. Whether to unify the module name across platforms.<br class="">2. What to name the module.<br class=""><br class="">Alternatives considered on point #1 (whether to unify) include:</div><div class=""><br class=""></div><div class="">1a. The status quo: I consider this to be undesirable for the reasons stated in "Motivation". To reiterate: the current system forces users to go out of their way to write cross-platform Swift code, as opposed to writing code that "just works" everywhere.<br class=""></div><div class="">1b. The current Darwin and Glibc modules are a combination of POSIX and the C standard library. We could export *two* modules. However I believe this introduces additional overhead for users, with only the marginal benefit of clean separation between libc and POSIX.<br class="">1c. A special import statement, defined in the Swift stdlib, that would automatically get preprocessed to the five lines of boilerplate shown above. This has several downsides, most notably the added complexity to Swift syntax.<br class=""><br class="">On point #2 (what to name it), I have spoken with people that raised concerns over the name "Libc":</div><div class=""><br class=""></div><div class="">> Another concern is about compatibility with the C++ modules proposal. If we want this module name to mean something, it should agree with the C++ spec.</div><div class=""><br class=""></div><div class="">I don't know which name was chosen in the C++ spec. I've been searching WG21 papers with no luck--any advice on how to find out would be appreciated!<br class=""><br class="">Aside from the above point, some concrete alternatives for point #2 (what to name it) include:</div><div class=""><br class=""></div><div class="">- `import System`: This is better suited to the idea that the module contains both POSIX and libc.</div><div class="">- `import C`: Drop the "Lib"--just "C". It's cleaner. (<a href="https://www.youtube.com/watch?v=PEgk2v6KntY" target="_blank" class="">https://www.youtube.com/watch?v=PEgk2v6KntY</a>)<br class=""><br class="">---<br class=""><br class="">Thanks for taking the time to read this proposal draft! Feedback (on its contents or on how to proceed with the evolution proposal process) is greatly appreciated.<br class=""><br class="">- Brian Gesiak</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><br class=""></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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>