<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On Oct 26, 2016, at 1:11 AM, alessandro aresta <<a href="mailto:performerstone@gmail.com">performerstone@gmail.com</a>> wrote:</span><br><blockquote type="cite"><span>Ensure is more comprehensible, guard is for sure "always" been there in older languages... could it be kind of aliased somehow?</span><br></blockquote><span></span><br><span>No, we don’t introduce needless aliases for keywords like this.</span><br></div></blockquote><br><div>What about allowing internal non-type aliases?</div><div><div> alias ensure = guard //can't be public</div>I know it's kinda encroaching on "macro" territory, but can't we already do simple text substitutions by importing a #define from C? Would allowing non-type aliases really be any different?</div><div><br></div><div>It'd address the concerns raised by I think nearly all of the "term-of-art" vs "term-of-English" proposals. Prohibiting aliases from being declared as `public` would <i>guard</i> the language's namespace, and <i>ensure</i> that it doesn't get polluted with every library author's favorite alternate spelling(s).</div><div><br></div><div>- Dave Sweeris</div></body></html>