<div dir="ltr"><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important">You’re really in pun mode today, David! :)</p>
<p style="margin:0px 0px 1.2em!important">Even though I originally pitched this, I go along with the source-churn arguments people have made[1], and the one about <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);background-color:rgb(248,248,248);border-radius:3px;display:inline">ensure</code> potentially being used for something else in the future. But I do really like Marco’s suggestion of <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);background-color:rgb(248,248,248);border-radius:3px;display:inline">guard:</code> because it changes the interpretation…</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class="hljs language-swift" 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);background-color:rgb(248,248,248);border-radius:3px;display:inline;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) none repeat scroll 0% 0%">guard: x &gt; <span class="hljs-number" style="color:rgb(0,128,128)">0</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">return</span> }
</code></pre>
<p style="margin:0px 0px 1.2em!important">This now reads as: <em>This is a guard: x must be greater than zero, otherwise return</em>. The only issue is it has the same syntax as a break-label so becomes potentially ambiguous/confusing. Is there another way that could be achieved?</p>
<p style="margin:0px 0px 1.2em!important">[1] For larger changes, but I think some of the arguments against breaking changes are weak for smaller changes/refinements.</p>
<div title="MDH:PGRpdj48ZGl2PjxkaXY+WW91J3JlIHJlYWxseSBpbiBwdW4gbW9kZSB0b2RheSwgRGF2aWQhIDop
PGJyPjxicj48L2Rpdj5FdmVuIHRob3VnaCBJIG9yaWdpbmFsbHkgcGl0Y2hlZCB0aGlzLCBJIGdv
IGFsb25nIHdpdGggdGhlIHNvdXJjZS1jaHVybiBhcmd1bWVudHMgcGVvcGxlIGhhdmUgbWFkZVsx
XSwgYW5kIHRoZSBvbmUgYWJvdXQgYGVuc3VyZWAgcG90ZW50aWFsbHkgYmVpbmcgdXNlZCBmb3Ig
c29tZXRoaW5nIGVsc2UgaW4gdGhlIGZ1dHVyZS4gQnV0IEkgZG8gcmVhbGx5IGxpa2UgTWFyY28n
cyBzdWdnZXN0aW9uIG9mIGBndWFyZDpgIGJlY2F1c2UgaXQgY2hhbmdlcyB0aGUgaW50ZXJwcmV0
YXRpb24uLi48YnI+PGJyPjwvZGl2PmBgYHN3aWZ0PGJyPjwvZGl2Pmd1YXJkOiB4ICZndDsgMCBl
bHNlIHsgcmV0dXJuIH08YnI+PGRpdj5gYGA8YnI+PGJyPjwvZGl2PjxkaXY+VGhpcyBub3cgcmVh
ZHMgYXM6ICpUaGlzIGlzIGEgZ3VhcmQ6IHggbXVzdCBiZSBncmVhdGVyIHRoYW4gemVybywgb3Ro
ZXJ3aXNlIHJldHVybiouIFRoZSBvbmx5IGlzc3VlIGlzIGl0IGhhcyB0aGUgc2FtZSBzeW50YXgg
YXMgYSBicmVhay1sYWJlbCBzbyBiZWNvbWVzIHBvdGVudGlhbGx5IGFtYmlndW91cy9jb25mdXNp
bmcuIElzIHRoZXJlIGFub3RoZXIgd2F5IHRoYXQgY291bGQgYmUgYWNoaWV2ZWQ/PGJyPjxicj48
L2Rpdj48ZGl2PlsxXSBGb3IgbGFyZ2VyIGNoYW5nZXMsIGJ1dCBJIHRoaW5rIHNvbWUgb2YgdGhl
IGFyZ3VtZW50cyBhZ2FpbnN0IGJyZWFraW5nIGNoYW5nZXMgYXJlIHdlYWsgZm9yIHNtYWxsZXIg
Y2hhbmdlcy9yZWZpbmVtZW50cy48YnI+PC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">​</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 27 Oct 2016 at 13:31 David Sweeris via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">On Oct 26, 2016, at 1:11 AM, alessandro aresta &lt;<a href="mailto:performerstone@gmail.com" class="gmail_msg" target="_blank">performerstone@gmail.com</a>&gt; wrote:</span><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><span class="gmail_msg">Ensure is more comprehensible, guard is for sure &quot;always&quot; been there in older languages... could it be kind of aliased somehow?</span><br class="gmail_msg"></blockquote><span class="gmail_msg"></span><br class="gmail_msg"></div></blockquote></div><div dir="auto" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">No, we don’t introduce needless aliases for keywords like this.</span><br class="gmail_msg"></div></blockquote></div><div dir="auto" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"></div></blockquote><br class="gmail_msg"><div class="gmail_msg">What about allowing internal non-type aliases?</div><div class="gmail_msg"><div class="gmail_msg">    alias ensure = guard //can&#39;t be public</div>I know it&#39;s kinda encroaching on &quot;macro&quot; territory, but can&#39;t we already do simple text substitutions by importing a #define from C? Would allowing non-type aliases really be any different?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It&#39;d address the concerns raised by I think nearly all of the &quot;term-of-art&quot; vs &quot;term-of-English&quot; proposals. Prohibiting aliases from being declared as `public` would <i class="gmail_msg">guard</i> the language&#39;s namespace, and <i class="gmail_msg">ensure</i> that it doesn&#39;t get polluted with every library author&#39;s favorite alternate spelling(s).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Dave Sweeris</div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>