All the recent talk of removing opEquals and opCmp and possibly messing with
TypeInfos got me thinking again about the fact that running
 Object x;
 x == null;
will seg-v. Writing that generically the code
 T x;
 x == T.init
will work fine for T=int, T=double, T=char[] but for T=Object it will seg-v.
That seems evil. Is there any hope of changing that behavior? It would also
make porting Java (and the equivalent C/C++) simpler since code fragments
like
 if (x != null) { ... }
currently will seg-v if x actually turns out to be null. It's pretty
annoying to uncover those typos one by one during run-time testing.

-Ben

If you're having another go, then I will. :)

    x == y

should be automatically rewritten, for object types, as

    (null === x) ? (null === y) ? true : false : (x == y)

except where x and/or y can be deduced (by the optimiser, not by the programmer) to be non-null, in which case the rewritten form may be one of

    (null === x) ? false : (x == y)

    (null === y) ? false : (x == y)

    (x == y)

I continue to reject all the counter arguments that were espoused at the time this was raised - about 15 months' ago, if memory serves - and continue to maintain that this will dramatically increase robustness, reduce surprise, and, given Ben's arguments, also help enormously with generics. Furthermore, I state that this will have NO discernible performance cost, since most times that the automatic rewriting results in a test against null, that test would have been performed somewhere manually anyway.


But do I expect this to fly? No.


"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:cfatup$31ip$1@digitaldaemon.com...
> All the recent talk of removing opEquals and opCmp and possibly messing with
> TypeInfos got me thinking again about the fact that running
>  Object x;
>  x == null;
> will seg-v. Writing that generically the code
>  T x;
>  x == T.init
> will work fine for T=int, T=double, T=char[] but for T=Object it will seg-v.
> That seems evil. Is there any hope of changing that behavior? It would also
> make porting Java (and the equivalent C/C++) simpler since code fragments
> like
>  if (x != null) { ... }
> currently will seg-v if x actually turns out to be null. It's pretty
> annoying to uncover those typos one by one during run-time testing.
>
> -Ben