Issue #11034 has been updated by Grzegorz Bizon.


@Recursive Madman - *try* is not native function. It is Active Support Core Extension. 

Moreover implementation and behavior of try is not stable (is changing depending on Rails version), it will not work when creating train wrecks and is terribly ugly.

Of course - this can be, in some specific way, achieved by using gem (like *nil_conditional* gem), but, in my opinion, only native implementation will be reasonable enough. **Only native solution for that problem will be stable, consistent, short and concise.**

What do you think ?

Kind regards,
 Grzegorz

----------------------------------------
Feature #11034: Nil Conditional
https://bugs.ruby-lang.org/issues/11034#change-52053

* Author: Grzegorz Bizon
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Hi everyone !

Some time ago I was thinking about Nil Conditional Operator in Ruby (`??`). This would be particularly useful to avoid frequent checking for nil, and should behave and look like Null Conditional Operator introduced in C# 6.0.

I was thinking about something like this (assume `var` is nil or doesn't exist):

~~~ruby
var??.method1.method2(123, 345).method3 { |i| i == 1 }
=> nil
~~~

When `var` is nil or doesn't exist, code above should return nil or NilConditionalClass object instead of raising NoMethodError or NameError.
This can also work with methods (assume `var` exists):

~~~ruby
var.method1??.method2(a, b)
=> nil
~~~

When `var` exists and can receive `method1`, but `method1` returns nil - this shouldn return nil instead of raising  `NoMethodError: undefined method `method2' for nil:NilClass`

When `var` exists and is not nil, and can receive `method1`, and object returned by `method1` can receive `method2` this, of course should behave as expected (like version without `??` operator) and return value according to implementation of method2.

When `var` doesn't exist - this should raise NameError.


I tried to create gem for that (https://github.com/grzesiek/nil-conditional) but from now on, only native implementation seems reasonable.

What do you think about that feature ? Maybe it is already considered, but I couldn't find anything similar at Google/this issue tracker (in that case I'm sorry for duplicate).

Thanks in advance for feedback !

Kind regards,
 Grzegorz




-- 
https://bugs.ruby-lang.org/