PROPOSAL: Byte and Short Integer Literal Suffixes

[brucechapman at paradise.net.nz]

Quoting Joe Darcy <Joe.Darcy at Sun.COM>:

> 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.

short was added for completeness of both proposals. I wouldn't see any practical
issues if short (and char) were removed from either of these proposals. So the
auto form would just be byte, int and maybe long. The suffix form if that route
was chosen would be just to add byte. 

My personal preference would be for the auto form, unless someone can find a
nice way to combine the advantages of both and avoid the missing bits from each
(auto form doesn't cover decimal and octal). 

Bruce

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