The cast(signed), cast(unsigned) feature proposal
Idan Arye
GenericNPC at gmail.com
Fri Jun 7 18:35:32 PDT 2013
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.
More information about the Digitalmars-d
mailing list