PROPOSAL: Byte and Short Integer Literal Suffixes

[Derek Foster]

-----Original Message-----
>From: Joe Darcy <Joe.Darcy at Sun.COM>
>Sent: May 19, 2009 9:05 PM
>To: Bruce Chapman <brucechapman at paradise.net.nz>
>Cc: "coin-dev at openjdk.java.net" <coin-dev at openjdk.java.net>
>Subject: Re: PROPOSAL: Byte and Short Integer Literal Suffixes
>
>Hi Bruce.
>
>Between your two proposals "Byte and Short Integer Literal Suffixes" and 
>"Auto Typing Hexadecimal and Binary Integer Literals," the suffixes are 
>more in keeping with the existing flavor of Java literals.  I'm more 
>inclined for support to be added for narrow (or auto) literals for bytes 
>rather than shorts since my impression is short is rarely used and those 
>annoying casts of values 0xF1 to byte are much more common.

Hi, Joe.

How often shorts are used depends a bit on the domain -- I am currently working on modifications for Eclipse to debug programs running on a 16-bit processor, and shorts are used quite a bit since that is the word size of the processor. If a suffix is added for byte, I'd like to see one added for short as well.

Derek



>
>-Joe
>
>
>On 03/25/09 01:59 AM, Bruce Chapman wrote:
>> TITLE: Byte and Short Integer Literal Suffixes
>>
>> latest html version at
>> http://docs.google.com/Doc?docid=dcvp3mkv_0fvz5gx7b&hl
>>
>> AUTHOR(S): Bruce Chapman
>>
>> OVERVIEW
>>
>> Problems occur when trying to create literal byte values for known bit
>> patterns because byte is signed therefore 0x80 thru 0xFF are not valid
>> byte values.
>>
>> Working with bytes (binary files, network communications) can be
>> simplified by allowing byte size integer literals (and short for
>> consistency). Specifically allow hexadecimal byte literals, others for
>> completeness.
>>
>>
>>
>> FEATURE SUMMARY:
>>
>> Allow byte and short integer literals by introducing 4 new integer type
>> suffixes 'y' & 'Y' for bytes, 's' & 'S' for shorts.
>>
>>
>> MAJOR ADVANTAGE:
>>
>> Somewhat reduces the pain resulting from byte being a signed type,
>> removes the need to downcast integer literals to byte or short.
>>
>>
>> MAJOR BENEFIT: Why is the platform better if the proposal is adopted?
>>
>> cruddy code like
>>
>>      byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};
>>
>> can be recoded as
>>
>>
>>
>>      byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };
>>
>> MAJOR DISADVANTAGE:
>>
>> Some familiarisation curve required before the syntax stops looking
>> slightly odd.
>>
>> Would prefer to but cannot use 'B' as Integral type suffix because it is
>> a hexadecimal digit, 'Y' can be used but is slightly esoteric, but
>> probably no more so than 'X' for hexadecimal prefix.
>>
>>
>> ALTERNATIVES:
>>
>> An alternative language change would be to have hexadecimal integer
>> literals that are typed according to the number of digits.
>>
>> EXAMPLES
>> Show us the code!
>> SIMPLE EXAMPLE:
>>
>>
>>      byte[] utf8bom7 = { 0xEFy, 0xBBy, 0xBFy };
>>
>>
>> ADVANCED EXAMPLE:
>>
>>
>>      byte[] buffer = ...;
>>
>>      if(buffer[i] == 0xBBy) { // never equal with 0xBB
>>
>>         ...
>>
>>      }
>>
>> DETAILS
>> SPECIFICATION:
>>
>>
>> "3.10.1 Integer literals" is amended  as follows - additions in bold.
>>
>>
>>      IntegerTypeSuffix: one of
>>      l L y Y s S
>>
>>
>>      An integer literal is of type long if it is suffixed with an ASCII
>> letter L or l (ell), of type short if it is suffixed with an ASCII
>> letter S or s and of type byte if it is suffixed with an ASCII letter Y
>> or y; otherwise it is of type int (§4.2.1).  For long literals the
>> suffix L is preferred, because the letter l (ell) is often hard to
>> distinguish from the digit 1 (one).
>>
>>
>>
>> and at the end of 3.10.1 add
>>
>>      A compile-time error occurs if a decimal literal of type short is
>> larger than  32767 (215), or if the literal 32767 appears anywhere other
>> than as the operand of the unary - operator, or if a hexadecimal or
>> octal short literal does not fit in 16 bits.
>>
>>      A compile-time error occurs if a decimal literal of type byte is
>> larger than  128 (27), or if the literal 128 appears anywhere other than
>> as the operand of the unary - operator, or if a hexadecimal or octal
>> byte literal does not fit in 8 bits.
>>
>>
>> COMPILATION: How would the feature be compiled to class files? Show how
>> the simple and advanced examples would be compiled. Compilation can be
>> expressed as at least one of a desugaring to existing source constructs
>> and a translation down to bytecode. If a new bytecode is used or the
>> semantics of an existing bytecode are changed, describe those changes,
>> including how they impact verification. Also discuss any new class file
>> attributes that are introduced. Note that there are many downstream
>> tools that consume class files and that they may to be updated to
>> support the proposal!
>>
>> TESTING: How can the feature be tested?
>>
>> LIBRARY SUPPORT:
>>
>> No library support required.
>>
>> REFLECTIVE APIS: Do any of the various and sundry reflection APIs need
>> to be updated? This list of reflective APIs includes but is not limited
>> to core reflection (java.lang.Class and java.lang.reflect.*),
>> javax.lang.model.*, the doclet API, and JPDA.
>>
>> OTHER CHANGES: Do any other parts of the platform need be updated too?
>> Possibilities include but are not limited to JNI, serialization, and
>> output of the javadoc tool.
>>
>> MIGRATION: Sketch how a code base could be converted, manually or
>> automatically, to use the new feature.
>>
>> COMPATIBILITY
>> BREAKING CHANGES: Are any previously valid programs now invalid? If so,
>> list one.
>>
>> EXISTING PROGRAMS: How do source and class files of earlier platform
>> versions interact with the feature? Can any new overloadings occur? Can
>> any new overriding occur?
>>
>> REFERENCES
>> EXISTING BUGS: Please include a list of any existing Sun bug ids related
>> to this proposal.
>>
>> URL FOR PROTOTYPE (optional):
>>
>>
>>   
>
>