[ruby-core:75570] [Ruby trunk Feature#12263] Feature request: &&. operator (shorthand for foo && foo.method)

From: danieldasilvaferreira@...
Date: 2016-05-17 15:32:13 UTC
List: ruby-core #75570
Issue #12263 has been updated by Daniel Ferreira.


I understand that.
But it comes in line with more or less the same logic of the lonely operator in a different way, do you agree with me?
Shall we have separate operators for each one of these situations or try to come up with an operator that will handle everything in a clever way?
For me the logic would be to call a method in an object whatever it is and return a default value if the object does not respond to the method call.

Nobuyoshi Nakada wrote:
> Daniel Ferreira wrote:
> > Maybe the proposed `&&.` operator would be a good case scenario for this situations acting like `Hash#fetch` this way:
> > 
> > ~~~ ruby
> > class Foo
> >   def bar(baz)
> >      baz&&.(:qux, 'whatever')
> >   end
> > end
> > ~~~
> 
> It seems different from the original proposal at all.



----------------------------------------
Feature #12263: Feature request: &&. operator (shorthand for foo && foo.method)
https://bugs.ruby-lang.org/issues/12263#change-58704

* Author: Johnny Shields
* Status: Feedback
* Priority: Normal
* Assignee: 
----------------------------------------
Ruby 2.3 introduced the `&.` safe-navigation operator. I'd like to propose a `&&.` operator which would be shorthand for:

~~~ruby
foo && foo.method
~~~

Unlike `&.`, this does not continue the chain if the variable evaluates to `false`. This would give the following result:

~~~ruby
false&.class       # => FalseClass
false&&.class      # => false

false&.inexisting  # => raises NoMethodError
false&&.inexisting # => false
~~~



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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next