Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Joshua Cranmer Newsgroups: comp.lang.java.programmer Subject: Re: Java puzzler Date: Thu, 12 May 2011 10:33:34 -0400 Organization: A noiseless patient Spider Lines: 52 Message-ID: References: <4db69c13-878f-4806-adb2-a3c5adb1c48c@glegroupsg2000goo.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 12 May 2011 14:33:36 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="3xSaU6y5tAyBQEIxw+DaTw"; logging-data="25677"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+99pYkWdEYvMvcEWtEbjOFDe2wAF9N2hM=" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.16pre) Gecko/20110305 Lightning/1.0b3pre Thunderbird/3.1.10pre In-Reply-To: Cancel-Lock: sha1:tbT99NYb0+VYlQqur4P2cd7jzPQ= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4011 On 05/11/2011 04:57 PM, Tom Anderson wrote: > If we're talking about things like: > > byte b = 0; > b += 2; > > The i agree that that should compile - it would be agonizing if it > didn't. But i see no earthly reason why this: > > byte b = 0; > int i = 1000000; > b += i; > > Should compile. Where you're using a literal, you have no way to make > the literal one size of integer or another, but when you're using a > variable, you do; an offset for a byte can be a byte itself. Well, if you step back and look at it from the semantic point of view, what the compiler sees at both instances the following pattern: += . You could redefine literals of smaller numeric type, which makes the expression computation rules confusing (is (1001 - 1000) a byte, short, or int?). However, as long as byte, short, and char promote to int for integer computation, it still doesn't solve the += problem. You could change them to not promote to int, but that starts to cause interesting tangles in Java (the VM would either need to have instructions for all arithmetic instructions in byte, short, and char counterparts, in addition to the int, float, long, and double counterparts, or it would have to emit narrowing conversions after every subcomputation in an expression). But I can see reasons to allow your `b += i' expressions. Consider that use of the byte and short types are relatively rare, as they are only effective in memory reduction when used in arrays [1]. It is not unimaginable that many constants have type int but are naturally applicable to byte or short values. In such a case, b += i would make sense. > So, would it have been possible to write the language rules such that > integer literals have either some sort of indeterminate-length > pseudo-type that can be used submissively in all sorts of expressions, > or to have small integer literals have type byte, bigger ones type > short, and so on? Yes, it would have been possible, but if you throw in the results of compile-time constant expressions, things might get ugly. It also makes computing the type of a literal somewhat uglier for rather little benefit. [1] Well, the JVM could theoretically pack bytes, shorts, and chars inside classes, but I'm not sure if this is done in practice. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth