I opened GROOVY-7557 <https://issues.apache.org/jira/browse/GROOVY-7557> for this. If we can get the behavior consistent, it'd greatly simplify that giant second table since I would just be able to say something like "the primitives have the same behavior as their wrappers" and leave half the table off.
-Keegan On Tue, Aug 25, 2015 at 2:08 AM, Jochen Theodorou <[email protected]> wrote: > Am 25.08.2015 01:01, schrieb Keegan Witt: > >> I ended up putting this in the Java vs Groovy section instead of where I >> originally planned because it occurred to me that these conversions >> apply to more than just assignment (e.g. method invocation). Here's >> what I have so far: https://github.com/apache/incubator-groovy/pull/98. >> >> Besides wanting any feedback you might have (especially on other options >> for the second table), I also wondered if these behaviors were >> intentional: >> >> * char -> byte requires a cast in Java, but doesn't in Groovy (even >> with CompileStatic) >> > > the cast is like a security feature in Java, which we don't use in normal > Groovy. That's why you can for example assign a long to a byte too. > @compileStatic behaves different in that, but maybe this conversion has > been forgotten > > * Most boxing/unboxing works with CompileStatic, but not char -> >> Character or Character -> char >> > > that looks like a bug to me > > * Several inconsistencies around when casts are needed when working >> with CompileStatic (e.g. short -> int and short -> Integer, and char >> -> int work, but not char -> Integer) >> > > looks like char conversion is missing some aspects. I guess this is also > due to the analogy of 1-char Strings and Character we use in normal Groovy > (not supported by @CompileStatic) which did let us forget about some > transformations > > bye blackdrag > > -- > Jochen "blackdrag" Theodorou > blog: http://blackdragsview.blogspot.com/ > >
