Thoughts on unified integer literal improvements

[Weijun Wang]

brucechapman at paradise.net.nz wrote:
> Quoting Weijun Wang <Weijun.Wang at Sun.COM>:
> 
>>> long ell = 0xFFFFFFFFu; // A positive long value
>> Any particular requirement here? Why not simply
>>
>>  long ell = 0xFFFFFFFFl;
>>
>>> I think this approach has some advantages over the "y" suffix; in 
>>> particular I think it gives more desirable behavior in cases like
>> this:
>>> byte b = 0xFFy // a negative byte value
>>> byte b = 0xFFu // also a negative byte value
>>>
>>> short s = 0xFFy // a negative short value, -128;
>>> // byte value is signed extended
>>> short s = 0xFFu // a positive short value, +127
>>>
>>> int i = 0xFFy // -128
>>> int i = 0xFFu // 127
>> Does this mean the actual value of 0xFFu is determined by looking at
>> the
>> LHS of the assignment? This is terrible.
> 
> Yes that would be terrible if it were true, fortunately it is not. The value is
> determined by the digits and any radix specified by the prefix.  In the above
> examples, the "y" suffix means byte, so when is widened to a short or int it
> sign extends and stays negative. The "u" suffix would create a special type that
> would always zero extend when widening giving a positive number.

I still find it difficult to understand this 'u' thing. When you say
"zero extend when", isn't that the same with what I said "depending on
the LHS"?

What is the most important usage of it?

> 
>> I'd rather use something like 0bXX which is itself always a byte
>> literal.
> 
> But that is inconsistent, prefixes currently determine radix, suffixes determine
> type. Also the binary literals part of the proposal is using 0b as a prefix for
> binary literals so 0bXX is an int.

I see.

Thanks
Max

> 
> Bruce
> 
>> Max
>>
>>> -Joe
>>>
>>  
>