Project

General

Profile

Feature #12263

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

Added by johnnyshields (Johnny Shields) about 3 years ago. Updated almost 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:74852]

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

History

Updated by johnnyshields (Johnny Shields) about 3 years ago

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

Updated by nobu (Nobuyoshi Nakada) about 3 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) about 3 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) about 3 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) almost 3 years ago

Real world use case, please?

Matz.

Updated by dsferreira (Daniel Ferreira) almost 3 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) almost 3 years ago

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.

Updated by nobu (Nobuyoshi Nakada) almost 3 years ago

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

Updated by dsferreira (Daniel Ferreira) almost 3 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) almost 3 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.

Also available in: Atom PDF