hg: jdk7/tl/langtools: 6979683: inconsistent interaction of reference cast with box/unbox conversions leaves out a useful case

[John Rose]

On Sep 2, 2010, at 12:07 PM, Neal Gafter wrote:

> It isn't gray.  Combined conversions are not intended to be allowed.

I accept your statement that they are not *intended*, but my contentions are about the *reading* of the spec.

Consider this text from 5.2 Assignment Conversion in JLS3:
  Assignment contexts allow the use of one of the following: ...

Consider this parallel text from 5.3:
  Method invocation contexts allow the use of one of the following: ...

Now consider this from 5.5:
  Casting contexts allow the use of: ...

See the difference?  Maybe it wasn't *intended*, but it's *there*.

Is that a significant?  Logically, yes.  Also, notice that all implementations seem to allow the combined cast (Object)(int) => (Object)(Integer)(int).  I have asked you, but you still haven't proposed an alternative theory of why that is allowed by the spec.

But there's more.  Consider the language from the next paragraph of 5.5:
  Thus casting conversions are more inclusive than assignment or method invocation conversions: ...

Note that, if we take your interpretation (one step only for a cast) which as I have shown is not the language of the spec., then that text from the spec. is false.  For example, this line from 5.2:
  an unboxing conversion (§5.1.8) optionally followed by a widening primitive conversion

...describes a conversion which is strictly *more* inclusive than the this line from 5.5:
  an unboxing conversion (§5.1.8)

Neal, I'm curious.  Apart from the departure from the spec. (which I dispute), do you think the language ought not to include the reverse combined cast (int)(Object) => (int)(Integer)(Object)?  I thought you were a contributor to the proposal for clarifying the spec. (or extending it, in your view) that includes the reverse cast that I have implemented.

-- John