the point is to avoid breaking code.<div>Since no-one can possibly use cast(unsigned) currently, introducing Cast and recommending using Cast instead of cast() will not break any code and provide room for library based cast extensions.</div>
<div><br></div><div>The smaller the symbols in scope and the shorter the syntax the better; I doubt you're using cast() in all your modules anyways.</div><div><br></div><div>However, I very much do support language syntax sugar when it provides advantages over a library solution: </div>
<div><br></div><div>* tuples (see DIP), </div><div>* named parameter argument (see threads)</div><div>* and even to some extent := (your suggestion!)</div><div><br></div><div><div class="gmail_quote">On Fri, Jun 7, 2013 at 7:24 PM, Mrzlga <span dir="ltr"><<a href="mailto:bulletproofchest@gmail.com" target="_blank">bulletproofchest@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 class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
not suggesting deprecating cast(), just suggesting there's no need to<br>
extend the language as it can be done in library code, advantageously. It's<br>
trivially extensible as I wrote it. However, any language extension has to<br>
be re-implemented by each compiler implementation.<br>
</blockquote>
<br>
<br></div>
I don't think you can simultaneously try to not-suggest deprecating cast() shortcuts, and do-suggest there's no need to extend the language as it can be done in library code, while suggestiing duplicating cast() shortcuts. Your point would make sense if you were trying to get rid of the shortcuts. Otherwise you should argue for signed(x) / unsigned(x)<br>

<br>
Make it consistent.<br>
</blockquote></div><br></div>