

C# is getting “?.”, sometimes called the Safe Navigation Operator - mendicant
http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

======
mcv
Great news. The ?. operator in Groovy greatly reduces boilerplate code and
improves readability and maintainability. No layers of null pointer checks
that are all basically the same and getting in the way of what you actually
want to do.

And in those cases where you still need specific behaviour based on which
object is null, you can still use the . operator with traditional null pointer
checks.

------
mendicant
The question I have about this: Does making it easy to do
parent?.child?.grandchild?.property help or hinder the software development
process in the long term?

~~~
vorg
The ?. has only really worked in scripting, i.e. writing quick scripts to
manipulate code written in a proper type-checked programming language. Groovy
has it but Java doesn't. In Groovy's heyday if some code spewed out
NullPointerException, the first thing people did was replace all the . with ?.
and run it again, because the code was throwable quality anyway. I can't
imagine anything good will come of putting ?. into C# (or Java) which is meant
for building more lasting systems.

~~~
gizmo686
Using ?. lets you do code like:

    
    
        var = foo()?.bar?.bing()
        if(foo==null){...}
    

instead of putting a null check between every call. In many cases null is used
to indicate that a computation failed. If you are doing a chain of
computations, there is often not a reason you need or want to do a check
between every computation, instead of having a single handler at the end for
if any of them fail.

This pattern comes up fairly often in Haskell, which accomplishes it with the
Maybe monad.

~~~
mendicant
There are certain languages and situations where the pattern does make sense.
But as a heavy C# coder, I find that more often than not you're dealing with a
class heavy codebase where it's more important that you _don'_ do
foo()?.bar?.bing(). Specifically as things happen such as refactoring you
often need to ask the question should something 'care' that a foo has a bar
which has a bing. Perhaps if you want to know about a bing that is down the
chain from Foo, perhaps Foo should provide you with the Bing somehow (which
really helps with refactoring as codebases grow to years and potentially
decades old).

It's not always so cut and dry, and there are situations where this is a very
valuable tool. I just feel that down the road if you feel like there is a
valid reason for refactoring object hierarchy that you'll potentially be doing
yourself (or those that follow) a disservice in the long run.

~~~
mcv
Yes, you could do that, but it goes against how everybody has been accessing
object properties for the past two decades.

Quite often, you simply want person.address.street.number, and if it doesn't
exist, you simply go on without it, and it doesn't matter what the exact
reason is why it doesn't exist. This is an extremely common and practical
pattern, and it's hindered by layers of null pointer checks.

