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.

The smaller the symbols in scope and the shorter the syntax the better; I doubt you're using cast() in all your modules anyways.

However, I very much do support language syntax sugar when it provides advantages over a library solution:

* named parameter argument (see threads)

* and even to some extent := (your suggestion!)

On Fri, Jun 7, 2013 at 7:24 PM, Mrzlga <bulletproofchest@gmail.com> wrote:

not suggesting deprecating cast(), just suggesting there's no need to
extend the language as it can be done in library code, advantageously. It's
trivially extensible as I wrote it. However, any language extension has to
be re-implemented by each compiler implementation.

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)

Make it consistent.