PROPOSAL: Byte and Short Integer Literal Suffixes

[Joe Darcy]

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.

-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):
>
>
>