Details

Type: Bug

Status: Resolved

Priority: P4

Resolution: Fixed

Affects Version/s: repovalhalla

Fix Version/s: repovalhalla

Component/s: tools

Labels:

Subcomponent:

CPU:generic

OS:generic
Description
Here are some notes from a discussion with Maurizio that need follow up:
Looking at the rules for 'reference conditionals' javac should apply
widening conversion in the following program's conditional expression and thereby type it to be X.I
public class X {
interface I {}
static class Node implements I {
}
static void foo(Node e) {
var ret = (e == null) ? new XNodeWrapper() : e;
}
static inline class XNodeWrapper implements I {
int i = 42;
}
public static void main(String [] args) {
}
}
(... "Otherwise, the second and third operands are of types S1 and S2 respectively. Let T1 be the type that results from applying boxing conversion to S1, and let T2 be the type that results from applying boxing conversion to S2. The type of the conditional expression is the result of applying capture conversion (§5.1.10) to lub(T1, T2).")
But, more specifically, conditionals are divided in 3 categories:
1) numeric conditionals > all operands are numerics (either boxed or unboxed)
2) boolean conditionals (boolean or Boolean operands)
3) reference conditonals
now, for (3) we go the widening way (e.g. we apply boxing)
but for (1) we say If one of the second and third operands is of primitive type T, and the type of the other is the result of applying boxing conversion (§5.1.7) to T, then the type of the conditional expression is T and there's also this: If the second and third operands have the same type, then that is the type of the conditional expression. So ideally here we need a section on value conditional expressions and the rules perhaps should be similar to those for numerics which try to return an unboxed value as much as possible
in other words, this is about whether we want inline classes to be more like Integer or like any reference class since our plan is to retrofit Integer to be an inline class perhaps this is a forced move and we have to stick with the numeric rules
So, 4 cases:
T.ref, T.ref > type is T.ref
T.val, T.val > type is T.val
T.ref, T.val > type is T.val
T.val, T.ref > type is T.val
now, in the NodeWrapper example, this is just a plain reference conditional, so javac should just apply widening
Looking at the rules for 'reference conditionals' javac should apply
widening conversion in the following program's conditional expression and thereby type it to be X.I
public class X {
interface I {}
static class Node implements I {
}
static void foo(Node e) {
var ret = (e == null) ? new XNodeWrapper() : e;
}
static inline class XNodeWrapper implements I {
int i = 42;
}
public static void main(String [] args) {
}
}
(... "Otherwise, the second and third operands are of types S1 and S2 respectively. Let T1 be the type that results from applying boxing conversion to S1, and let T2 be the type that results from applying boxing conversion to S2. The type of the conditional expression is the result of applying capture conversion (§5.1.10) to lub(T1, T2).")
But, more specifically, conditionals are divided in 3 categories:
1) numeric conditionals > all operands are numerics (either boxed or unboxed)
2) boolean conditionals (boolean or Boolean operands)
3) reference conditonals
now, for (3) we go the widening way (e.g. we apply boxing)
but for (1) we say If one of the second and third operands is of primitive type T, and the type of the other is the result of applying boxing conversion (§5.1.7) to T, then the type of the conditional expression is T and there's also this: If the second and third operands have the same type, then that is the type of the conditional expression. So ideally here we need a section on value conditional expressions and the rules perhaps should be similar to those for numerics which try to return an unboxed value as much as possible
in other words, this is about whether we want inline classes to be more like Integer or like any reference class since our plan is to retrofit Integer to be an inline class perhaps this is a forced move and we have to stick with the numeric rules
So, 4 cases:
T.ref, T.ref > type is T.ref
T.val, T.val > type is T.val
T.ref, T.val > type is T.val
T.val, T.ref > type is T.val
now, in the NodeWrapper example, this is just a plain reference conditional, so javac should just apply widening