Byte and short Integer Literals - discussion

Bruce Chapman brucechapman at
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 ) 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 

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.


More information about the coin-dev mailing list