Byte and short Integer Literals - discussion
Bruce Chapman
brucechapman at paradise.net.nz
Mon Mar 2 00:23:57 PST 2009
I am working on a proposal to add byte and short integer literals in
order to ease some of the pain caused by byte being a signed type when
most uses are just as a set of bits. Its mostly about byte size
hexadecimal literals but other forms should be considered for completeness.
One option ( work in progress at
http://docs.google.com/Doc?docid=dcvp3mkv_0fvz5gx7b&hl=en ) is to allow
integer type suffixes for byte (say y and Y) and short (say s and S) .
That fits into the existing spec quite easily but looks a bit odd e.g.
byte[] stuff = { 0x00y, 0x7Fy, 0x80y, 0xFFy };
Another approach would be to introduce a completely new syntax for
hexadecimal integer literals which are typed according to the number of
digits. for example (new syntax uses 0h compared with 0x for current int
literals)
byte b = 0hFF;
short s = 0hFFFF;
int i = 0hffffffff;
long l = 0hffffffffffffffff;
type determination would follow these rough rules.
1 or 2 digits -> byte literal
3 or 4 digits -> short
5 - 8 digits -> int
9 - 16 digits -> long.
leading zeros permissible eg
short s = 0h0000;
So question:
Do either of these stand out as superior (from a coin perspective) to
the other in any significant way? I'd like to spend the majority effort
on the better one if there is a significant preference on the mailing
list. I am of two minds which is why I am asking.
Bruce
More information about the coin-dev
mailing list