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