Thoughts on unified integer literal improvements

[Joseph D. Darcy]

Bruce Chapman wrote:
> Joe Darcy wrote:
>> Hello.
>>
>> On the set of improved integer literal features, I think combining 
>> the underscores as separators and binary literals is straightforward 
>> given separately correct grammars for each change.
>>
>> As an alternate to "y" and "s" suffices, I suggesting considering a 
>> "u" suffix to mean unsigned.  Literals with a trailing "u" would have 
>> type int; widening conversions of such literals would 0 extend and 
>> narrowing conversions would range check on the width of set bits.  
>> For example,
>>
> Doesn't that idea has some problems introducing it into the language 
> and type system?

I don't think the problems are insurmountable :-)

There would need to be new rules for primitive widening and narrowing 
conversion and on how "unsignedness" propagated.  For example, "0x2u  + 
0x1u" would probably *not* be considered unsigned, just a plain literal.

>
> if it is "Literals with a trailing "u" would have type int;" then the 
> type is int, and the value just the same as for when there was no 
> suffix. If the widening and narrowing changes behaviour for these 
> literals only, how can this be done unless these literals are of some 
> new type, or the type system knows about the notation used to declare 
> the value?  

The trailing "u" would trigger some new rules, but fundamentally they 
are just plain old int values once they are no longer considered a literal.

> And if we can have unsigned ints surreptitiously like this, then lets 
> have unsigned byte as well, and unsigned byte arrays. Yeeha - now I'm 
> really happy.   :)
>
>
>
> But taking that idea, and combining it with the autosizing integer 
> literal proposal such that we use the "u" suffix to denote autosizing 
> (rather than only having it work for hex literals with the 0h prefix), 
> now that might fly, and could work for decimal and octal and binary as 
> well.
>
> I'll have to do some more thinking thru on this, and now is not an 
> ideal time for me.
>
>> byte b = 0xABu // equivalent to (0xAB & 0xFF)
> do you mean // equivalent to (byte) 0xAB  ? (because (0xAB & 0xFF) is 
> already equivalent to 0xAB)
>>
>> long ell = 0xFFFFFFFFu; // A positive long value
> but
> int hell = 0xFFFFFFFFu; // -1  ???

Correct -- since "u" denoted an unsigned value, promoting an unsigned 
literal to a wider format 0 extends rather than sign extends.

>>
>> 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
> do you mean // a positive short value, +255?

Yes, I meant +255.

-Joe