Proposal: Elvis and Other Null-Safe Operators

[Jeremy Manson]

> The principle perceived disadvantage, however, is that it encourages,
> rather than discourages, the use of null values in APIs.

I would think that the principle disadvantage would be not that it
encourages use of null values (which, as you point out, is fine in
some contexts), but that it encourages programmers not to think about
what happens when there is a null value.  I can easily imagine
programmers using this all of the time without thinking about it, and
then being surprised when a null ends up in the wrong place and not
knowing how it got there.  Even with a simple example:

public String someFunction(String a, String b) {
  String s = a?.concat("foo");
  String t = b?.concat(a);
  return myHashMap?.get(t);
}

Now, someFunction returns null.  Is it because a was null?  Or b was
null?  Or myHashMap was null?  Or there was no mapping for t in
myHashMap?

I then imagine this spread out over 70 methods and 10,000 LOC, and
realize that problems will be much harder to track down.

In short, the danger is that lazy programmers start using this
construct when getting a null value actually matters.  I'd much rather
stick with fail-fast NPEs for this case.  If you want to cut down on
extraneous if-testing, I would use JSR-305's Nullity annotations
instead.

Jeremy