Thoughts on unified integer literal improvements

[brucechapman at paradise.net.nz]

Quoting Alex Buckley <Alex.Buckley at Sun.COM>:

> Hi Bruce,
> 
> Bruce Chapman wrote:
> > My preference at the moment is for the "u" suffix with autosizing 
> > semantics.
> 
> Just as well, since a new unsigned primitive type in the JLS is not on 
> the table in Coin.

OK, that's a pretty clear indicator.
> 
> > Some work is needed to define the autosizing rules exactly - I am 
> > currently leaning toward (loosely)
> > 
> > The type of the literal is the smallest integral type capable of 
> > holding all significant bits of the constant, unless the first
> > digit of the literal (excluding prefix characters) is '0' in which 
> > case the type is the smallest integral type capable of holding one
> more 
> > than the number of significant bits of the constant value. eg 0xFFu is
> 
> > byte, 0x0FFu is short.
> 
> I personally tend to shy away from 'correct but clever' rules that make
> 
> the reader work hard to follow the types.

In the original autosizing which was just for hexadecimal, the size was
specified based on the number of digits. When you extend it to decimal and octal
as well, basing the size on number of digits gets real ugly, real fast. So "as
small as possible" seems more natural. A leading zero digit forces zero extend
by making it 1 bit bigger before determining the type, thereby ensuring a zero
value high bit when the literal has a leading zero. That seems quite a natural
thing to do as well. Obviously more work is needed on specifying that behaviour
but I am still happy with the concept. I guess if the leading zero rule was
dropped the only thing to be lost is the ability to create short literals less
that 255. Thoughts?

> 
> > 1) "unsigned int" needs JLS changes that are excessive comparative to
> 
> > their value, when compared to the other options.
> > 
> > 2) Having a new primitive type "unsigned int" which can only be used
> for 
> > literals, and cannot be used to declare variables has a high
> probability 
> > of being viewed negatively by the user community. Some users would
> wish 
> > for full unsigned support, and others would wish that it wasn't there
> at 
> > all. The effort cost of explaining this afterwards will be
> significant
> 
> Thumbs up so far!
> 
> > 3) Explicit use of leading '0' digit in autosizing case to force zero
> 
> > extension is a good thing.
> > 
> > 4) One way to deal with the octal literal vs leading zero widens 
> > conflict would be to introduce alternate alphabetic prefixes for
> decimal 
> > (d) and octal (o) eg 0d10 (10) and 0o10 (8) which could be used in 
> > combination with a leading 0 digit to force zero extend (eg 0d0255u is
> 
> > short value 255)- however I assume this is unjustifiable complexity.
> 
> Unjustifiable, correct. Triggering autosizing with a leading 0 almost 
> seems like a clash for the sake of it! Keep autosizing out unless 
> experience with prototypes shows that the other integer literal 
> improvements are worthless without it.

The autosizing (if we pursue that) would be triggered by the "u" suffix, the
leading zero would just ensure that the resulting literal had at least its most
significant bit set to zero - therefore ensuring zero extend when widening -
which approximates Joe's semantics without the special "unsigned int" type. Does
that change your opinion on autosizing?


> 
> Alex
>  

Thanks for your comments

Bruce