The cast(signed), cast(unsigned) feature proposal

Timothee Cour thelastmammoth at gmail.com
Fri Jun 7 19:33:38 PDT 2013


the point is to avoid breaking code.
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:

* tuples (see DIP),
* named parameter argument (see threads)
* and even to some extent := (your suggestion!)

On Fri, Jun 7, 2013 at 7:24 PM, Mrzlga <bulletproofchest at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130607/4151c9a6/attachment.html>


More information about the Digitalmars-d mailing list