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

[Mrzlga]

> So, let me get this straight:
>
>  * You don't want `cast(signed)`, because of the range 
> difference between the types.
>  * You want `cast(signed int)` but not as syntactic salt - 
> which means you still want `cast(int)` to work.
>
> How about `cast(/*signed*/ int)`?


- I do want cast(signed)

- I don't want to suggest cast(int) should not work, but rather 
to think of a solution for better documentation in the code, and 
to encourage people to write:
     cast(signed) // when they're casting unsigned->signed
     cast(int)    // when they're casting short->int

- I still feel slightly uneasy about the previous point. What I 
mentioned about cast(signed int) was a form of brainstorming. I 
wanted to try to give some consideration to people who'd want the 
destination datatype to be explicit, as it says something about 
the destination range. However, the fact that we must be careful 
of the range is already implied by cast(signed) and 
cast(unsigned).

- I like how cast(const) uses the lowercase const and the same 
const keyword. There's a nice consistency about that. So I don't 
want them in the library.

- Cast operations should be available without module imports.

- I would use the cast(signed) and feel comfortable.

- I could use the signed(x) and enjoy it! cast(signed) is not a 
super important thing like the :=

- I think *your* idea was good and possibly better than mine, as 
it allows library authors to create new numerical types that 
support signed/unsigned casting, and yet still access it via 
cast(signed) if 'signed' was the template.

- I'm not sure if Walter & Andrei would want 
cast(ToWorkWithTheTemplates).


Regards,
z