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

[Idan Arye]

On Saturday, 8 June 2013 at 00:43:28 UTC, Mrzlga wrote:
> "doing nothing but converting unsigned->signed" is a dubious 
> statement.
>
> They are still screwing with the range, they are not just 
> "doing nothing but converting unsigned->signed".
> And 'int' says something about the outcome.
>
> So I am really asking for:
>
> cast(signed int) x;   // make them poor programmers write this, 
> lol
>
> That's not what I actually want, but at least it shows: We're 
> making a signed conversion, AND we're screwing with the range 
> to make it into an int.
>
> for further thought.

So, you want a syntactic salt that will force people to write 
`cast(singed int)` instead of `cast(int)` and `cast(unsigned 
int)` instead of `cast(uint)`?

What if they are not casting from a number? What if I want the 
ASCII value of a character - for example, `cast(int)'a'`? Will I 
have to write `cast(signed int)'a'`, or is this syntactic salt 
just for casting from numeric types?

I'm against this syntactic salt proposal. Programmers should know 
that `int` is signed and `uint` is unsigend, and I see little 
point in forcing them to acknowledge that whenever they do a 
numeric cast.

Also, casting to unsigned with implicit type is dangerous, since 
cast(uint)-1 == 4294967295 != 18446744073709551615 == 
cast(ulong)-1, but casting to signed is less dangerous, since it 
only affects large numbers. So the syntactic salt is more 
important for `cast(uint)` than for `cast(int)` - but `unit` 
already clarifies that the type is unsigned.