Question on layer/peeling

[John Rose]

On Jan 6, 2015, at 2:37 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> On 06/01/15 20:38, Michael Barker wrote:
>>> The trick can also be coaxed to give semi-plausible semantics to seemingly
>>> bogus expressions like "x == null" or "x == (Object)y" (for any x).  If "x"
>>> is a primitive, since autobox conversions never produce "null", then "x ==
>>> null" and "x == (Object)y" are complicated ways of saying "false".  But
>>> this doesn't help with nulling assignments like "a[i] = null"; there you
>>> need "T.null" (my bikeshed preference to "default(T)").
>>> 
>> I think allowing x == null (always false) and a[i] = T.null for value types
>> would certainly make the coding simpler as it would avoid layering for a
>> number of very common cases.  In the null comparison case I would assume
>> that Hotspot could easily throw away the condition altogether in the
>> specialised class.
> I think we should distinguish between default value and null value;

Totally agree; the concepts cannot be merged.  (The bikeshed colors may be similar or different; it doesn't matter much.)

> I believe null only makes sense for references

Totally true for new code.  My only point is that "honorary promotion of T to Object" might help retrofit some old code that was written for Objects.  In a DWIM-my sort of way.

This POV is consistent with having warnings like "x == null did you really mean x == T.null or Optional<T>.none()?".

Throwing static typing errors (with similar messages) would of course force the "did you really mean" question to happen earlier.

> - while default value makes sense in a broader sense. You don't want end up mixing the two concepts - as you would end up that i.e. int.null is 0 (zero), which happens to be quite a common value...

Yes.  We are a long way from the place where (int)null gets forced to zero, and we shouldn't go there now.

(I don't argue bikeshed colors, and perhaps you don't like mine, which is OK!)

— John