Thoughts on unified integer literal improvements
Joseph D. Darcy
Joe.Darcy at Sun.COM
Thu May 28 13:42:23 PDT 2009
Bruce Chapman wrote:
> Joe Darcy wrote:
>> 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
> 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
> 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.
More information about the coin-dev