Kurt Stephens

This definitely results in more succinct code. The only downside other than breaking code that depend on nil’s throwing exceptions would be isolating the points in the method chains that result in the origiNil values.

I definitely agree that code like this is a bad idiom that I have seen all over the place:

def foo; bar && bar.baz && bar.baz.caz("x"); end

And code like this is equally bad in that it over-eagerly traps errors you might want to know about otherwise:

def foo; bar.baz.caz('x') rescue nil; end

I had considered implementing a proxy for a while, but it felt at least as visually expensive and probably computationally too:

def foo; bar.if.baz.caz('x').else(nil); end

There’s a nice sense of simplicity in your solution. It clashes with the WhinyNil approach of ActiveSupport/Rails – though I see that with good test coverage the impact on losing warnings caused by method calls on nil might be negligible.

Cool idea.