Question on layer/peeling

[Vitaly Davidovich]

I agree; null should stay as a reference-only concept and specialized
generic code should use default for the type.

By the way, C# solves this by having TryGet type of methods that return a
boolean indicating success (I.e. found mapping) and set an out parameter to
the value found.  You'd need a lightweight tuple or multi return to do the
same in java,  I think.

Sent from my phone
On Jan 6, 2015 5:38 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; I
believe null only makes sense for references - 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...

Maurizio