Feature #12263
closedFeature request: &&. operator (shorthand for foo && foo.method)
Description
Ruby 2.3 introduced the &.
safe-navigation operator. I'd like to propose a &&.
operator which would be shorthand for:
foo && foo.method
Unlike &.
, this does not continue the chain if the variable evaluates to false
. This would give the following result:
false&.class # => FalseClass
false&&.class # => false
false&.inexisting # => raises NoMethodError
false&&.inexisting # => false
Updated by johnnyshields (Johnny Shields) over 8 years ago
- Subject changed from Feature request: &&. operator (foo&&.method) to Feature request: &&. operator (shorthand for foo && foo.method)
Updated by nobu (Nobuyoshi Nakada) over 8 years ago
- Description updated (diff)
- Status changed from Open to Feedback
&.
was considered useful because of try!
.
Is method call on an expression which may be false
so frequent?
Updated by shevegen (Robert A. Heiler) over 8 years ago
I don't really like it.
matz said that & is the lonely operator because the person is staring
at a dot before, like &.
&&. would be too lonely because now you have 2 people staring at a
dot together. This would make ruby hackers too sad.
In general I do not like the amplification of some tokens; for instance,
@foo is much nicer than @@foo.
I am also sure that, if you add this, people will suggest $$ as well. :)
I also have to admit that I find "x && y" easier to understand than
"x&&.y".
Updated by phluid61 (Matthew Kerwin) over 8 years ago
Robert A. Heiler wrote:
I also have to admit that I find "x && y" easier to understand than
"x&&.y".
But one could argue that the following, which is semantically equivalent to the proposed &&.
, is harder to understand:
(tmp = x) && tmp.y
The only question I have is whether it really has enough utility to warrant adding it as a language construct. (And what of the precedent: will |.
and ||.
be proposed next?)
Updated by matz (Yukihiro Matsumoto) over 8 years ago
Real world use case, please?
Matz.
Updated by dsferreira (Daniel Ferreira) over 8 years ago
Hi Matz,
I tend to still use this kind of code in some scenarios, specially when I work with objects with dynamic interfaces or arguments with different possible object types.
class Foo
def bar(baz)
if baz.respond_to?(:qux)
return baz.qux
end
'whatever'
end
end
Updated by nobu (Nobuyoshi Nakada) over 8 years ago
Daniel Ferreira wrote:
Maybe the proposed
&&.
operator would be a good case scenario for this situations acting likeHash#fetch
this way:class Foo def bar(baz) baz&&.(:qux, 'whatever') end end
It seems different from the original proposal at all.
Updated by nobu (Nobuyoshi Nakada) over 8 years ago
obj.(args)
is a syntax sugar for obj.call(args)
.
Your notation confuses me.
Updated by dsferreira (Daniel Ferreira) over 8 years ago
I opened a new feature request to extend the safe navigation operator. https://bugs.ruby-lang.org/issues/12412
I believe that with my proposal the aim of this feature request can also be achieved.
Updated by dsferreira (Daniel Ferreira) over 8 years ago
By implementing https://bugs.ruby-lang.org/issues/12412
We would get the desired behaviour:
false&.class # => FalseClass
false&.inexisting # => nil
For me the situation:
false&.class
it is a particular situation that can be handled using extra logic.
I don't think there are enough case situations to justify the addition of a new operator to the language.
And by extending the safe navigation operator we will be making use of an already existent language feature.