Feature #12263: Feature request: &&. operator (shorthand for foo && foo.method)

• Status: Feedback
• Assignee: -
• Target version: -

[johnnyshields (Johnny Shields)]

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

[johnnyshields (Johnny Shields)]

• Subject changed from Feature request: &&. operator (foo&&.method) to Feature request: &&. operator (shorthand for foo && foo.method)

[nobu (Nobuyoshi Nakada)]

• 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?

[shevegen (Robert A. Heiler)]

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".

[phluid61 (Matthew Kerwin)]

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?)

[matz (Yukihiro Matsumoto)]

Real world use case, please?

Matz.

[dsferreira (Daniel Ferreira)]

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

[nobu (Nobuyoshi Nakada)]

Daniel Ferreira wrote:

Maybe the proposed &&. operator would be a good case scenario for this situations acting like Hash#fetch this way:

class Foo
  def bar(baz)
     baz&&.(:qux, 'whatever')
  end
end

It seems different from the original proposal at all.

[nobu (Nobuyoshi Nakada)]

obj.(args) is a syntax sugar for obj.call(args).
Your notation confuses me.

[dsferreira (Daniel Ferreira)]

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.

[dsferreira (Daniel Ferreira)]

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.