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

Mrzlga bulletproofchest at gmail.com
Fri Jun 7 13:52:52 PDT 2013


Hi guys,

This is a small feature proposal.
Please consider to add these to the language:

     cast(signed)
     cast(unsigned)


Motivation:

- To remove the need to write "cast(ulong) x" and repeat the 
underlying type, which is the same motivation as cast(const), 
cast(immutable), cast(shared)

- Reduce the strain of writing signed/unsigned conversions, so 
that making signed/unsigned conversions a compilation error is 
more palatable.

- Works as a new feature: if we have created a function or 
template which uses Concepts to accept just a signed number, we 
can use cast(unsigned) to generically cast any type X to the 
unsigned version.


Positives:

- cast(signed) is easy to type.

- cast(signed) is easy to see -- Scanning over the code with your 
eyes, we can see that the only intention was to make a cast about 
the signedness, but not about anything else.

- Works within the system of grepping for all casts.

- Works in the spirit of 'auto'.

- Consistent with cast(const), cast(immutable), cast(shared).


Downsides:

- Adds two keywords to the language.
     > They aren't the worst keywords, considering that C has them.

- 'unsigned already means something in C, let's not change how it 
works'

- Writing "cast(unsigned) x" is actually more text than 
"cast(ulong) x"
     > True, but the cast(unsigned) expresses the intention


Possible arguments against:

- The idea of 'no casts should be generic'

- Use the library for it and instead make signed(x), unsigned(x) 
templates.

     > Downsides to this solution: User can't easily grep for 
'cast' and find the 'unsigned(x)' template. It should be 
consistently greppable in the exact same way as other casts. 
Because it is a cast, so don't hide it.


That's it!

Thanks for your consideration :)


More information about the Digitalmars-d mailing list