Thoughts on unified integer literal improvements

[Joseph D. Darcy]

Weijun Wang wrote:
> Bruce Chapman wrote:
>   
>> Weijun Wang wrote:
>>     
>>> 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"?
>>>   
>>>       
>> No, The JLS defines a number of conversions, one of which is widening
>> and when that occurs. For example
>>
>> byte b = 1;
>>
>> int j = b+1;
>>
>> in the second line the type of the expression "b+1" is not determined by
>> the LHS, but the various conversion rules say that the b expression of
>> type byte must be widened to an int before the addition and assignment
>> occur in that order.
>>
>>
>> Similarly when we say
>>
>> short s = 0xFFu;
>>
>> What is happening is that the type of the expression on the right has
>> some conversions applied before the assignment. Collectively those are
>> called assignment conversion, and when 0xFFu has a type of byte, then
>> the particular assignment conversion which is applied is the widening
>> conversion.
>>     
>
> I somehow understand your point. This 0xFFu is a brand new data type.
>   

Not it is not; it is a more concise notation for expressing various 
constants more convenient.

> Don't know if it can be coined without any new VM bytecode. Implementing
>   

In two's complement arithmetic, add, subtract, and multiply give the 
same bit-level results for a signed and unsigned interpretation of the 
data.  For the basic operations, only a separate divide method would be 
needed.  There is no need for a new bytecode to support unsigned literals.

-Joe