Byte and short Integer Literals (original) (raw)

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