Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Lint cop to ask programmer to clarify foo.&bar into either safe navigation or bitwise and #11079

Closed
Qqwy opened this issue Oct 16, 2022 · 2 comments · Fixed by #11080
Closed

Comments

@Qqwy
Copy link

Qqwy commented Oct 16, 2022

Is your feature request related to a problem? Please describe.

Safe navigation uses the syntax foo&.bar.

However, when mistakenly writing foo.&bar instead, the Ruby parser happily accepts this.
After all:

   foo.&bar
== foo.& bar
== foo.&(bar)
== foo & bar

That is, this is interpreted as usage of the 'bitwise and' operator. (Or an overloaded version of the binary & operator).

While the Ruby parser has to accept this syntax, it is highly unlikely that a user uses the particular way of writing foo.&bar
to mean foo & bar.
It is much more likely that the user meant to use the safe navigation foo&.bar syntax instead.

Describe the solution you'd like

I would like a simple lint cop that warns when someone writes foo.&bar, and suggests the programmer to clarify:

  • Whether they meant foo&.bar
  • Or whether they meant foo & bar

Describe alternatives you've considered

I do not think that there are easy alternatives.

We cannot alter what the Ruby parser itself does for this kind of situation, since it has to remain consistent with how method dispatching works.

Extra context

One thing I am not sure about, is how to name this cop.

Lint/AmbiguousBitwiseAnd maybe?


What do you think?
I would gladly contribute a PR that implements this cop 😊 .

@koic
Copy link
Member

koic commented Oct 16, 2022

I think it's better if the semantics don't change.

# bad
foo.&bar

# good
foo & bar

So changing foo.&bar to foo & bar is a safer correction than changing it to foo&.bar. Either way, it's up to the user whether .& means & or &..

I've opened PR #11080 to solved the above.

@Qqwy
Copy link
Author

Qqwy commented Oct 16, 2022

Thank you! Your PR is a nice, much more general way to resolve this problem 💚!

koic added a commit to koic/rubocop that referenced this issue Oct 18, 2022
Closes rubocop#11079.

Checks for redundant dot before operator method call.
The target operator methods are `|`, `^`, `&`, `<=>`, `==`, `===`, `=~`, `>`, `>=`, `<`,
`<=`, `<<`, `>>`, `+`, `-`, `*`, `/`, `%`, `**`, `~`, `!`, `!=`, and `!~`.

```ruby
# bad
foo.+ bar
foo.& bar

# good
foo + bar
foo & bar
```

It accepts cases where the dot cannot be omitted. e.g.:

```ruby
foo.+@ bar
foo.+ bar.to_s
```
bbatsov pushed a commit that referenced this issue Oct 18, 2022
Closes #11079.

Checks for redundant dot before operator method call.
The target operator methods are `|`, `^`, `&`, `<=>`, `==`, `===`, `=~`, `>`, `>=`, `<`,
`<=`, `<<`, `>>`, `+`, `-`, `*`, `/`, `%`, `**`, `~`, `!`, `!=`, and `!~`.

```ruby
# bad
foo.+ bar
foo.& bar

# good
foo + bar
foo & bar
```

It accepts cases where the dot cannot be omitted. e.g.:

```ruby
foo.+@ bar
foo.+ bar.to_s
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants