Unexpected behavior in filter() when column name matches an environment variable

[bzbradford]

A friend and I have both encountered unexpected behavior from filter() and struggled to debug it until realizing that filter() was comparing a column against itself, instead of against a variable of the same name that had been defined elsewhere in the environment (for example, as a function argument).

library(dplyr)

# mtcars has 32 rows originally
nrow(mtcars)
# > [1] 32

# should show that 11 cars have 4 cylinders
mtcars |> filter(cyl == 4) |> nrow()
# > [1] 11

# should also show that 11 cars have 4 cylinders
cyl <- 4
mtcars |> filter(cyl == cyl) |> nrow()
# > [1] 32

Possible solutions:

• filter() warns when comparing a column against itself (which would return all rows), much like it warns when using a single = instead of double equal ==
• filter() first looks to the environment for a defined variable of the same name as the column when a column is possibly compared against itself

[moodymudskipper]

See ?rlang::dot-data, you might do :

mtcars |> filter(cyl == .env$cyl)

This is often used too :

mtcars |> filter(cyl == !!cyl)

That being said, since cyl == cyl never makes sense in filter, it could warn or even fail, because this issue is very common.

[DavisVaughan]

I think it would be tough to correctly and robustly detect these cases, so I don't think there is much we can do about this. I'm not sure cyl == cyl is really common enough to warrant an extra check for this