A few days ago, I changed the Mint [1] compiler to allow non-void code objects to be spliced in where statement form is required [2]:
Code x = ;
Code c = ;
This essentially generates the code below, which allows the 1 to be discarded:
;
Eddy pointed out that there is still a problem: Since I do a static type check on the type argument of Code<T>, the proper form cannot be determined if there is a wildcard Code<?>. We can check at run-time whether a code object is in statement form or whether it is an expression whose result needs to be discarded, but we cannot simply write an if-statement, because one of the alternatives would always be syntactically incorrect:
;
If c.isStat is true, then the else-branch is syntactically incorrect; if c.isStat is false, then there is a syntax error in the then-branch. Eddy pointed out that we can handle the Code<?> case, though, because the two branches are in future-stage code. That is, we can turn
into
if (c.isStat) {
} else {
}
Unfortunately, this gets more complicated if there is more than one Code<?> being escaped in. We would have 
cases, where 
is the number of Code<?> objects being stitched in:
would have to be turned into
if (c.isStat && d.isStat) {
} else if (c.isStat && !d.isStat) {
} else if (!c.isStat && d.isStat) {
} else {
}
I think for now I will change the compiler so that escaping a Code<?> in as a statement generates a compiler error. It seems like this is an unimportant corner case, and I don’t want to spend my time on something that is rarely beneficial. Again, this only happens for Code<?>, and only when escaping into bracket with a code block where statement form is required by Java rules.
