Re: byte + byte -> int
blue indigo wrote:
Mostly I have no gripes with Java's behavior in this area, but for the
"byte" type I make an exception. It really should have been unsigned, with
pure byte arithmetic always having type byte, so explicitly an unsigned
modulo-256 arithmetic. This better corresponds with how bytes are actually
used in working with low-level bit-twiddling and IO.
I think everyone will agree that making byte signed and not unsigned was
a really stupid decision.
About explicitly being modulo-256, I'm not entirely sure; I'm thinking
that most byte-level operations would essentially be ~, ^, &, and |,
although I seem to recall that those still require casting.
They also mishandled long -- it really shouldn't be necessary to stick an
extra L on the end of a long literal; literal integers should have been
treated as longs to begin with, and if they happened to fit in a narrower
type, been assignable to them without complaint. Instead, this is true for
int but you need to specify that a long literal is a long literal. That's
half-assed.
I'm not sure I agree with you that integer literals should be assumed to
be long (i.e., 1 is a long), but making a literal that's too large to be
an int a long might be helpful.
Of course it's too late to change any of this now without breaking tons of
existing code.
It would be extremely feasible to make a new signed byte type: the only
thing you need to do to the JVM is pick a new letter for signatures,
toss something for the anewarray opcode, and utilize & 0xff for the
int-to-signed byte opcode. The hardest part is the keyword.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth