What is the tidyeval equivalent of mutate_(mtcars, silly = ~mpg + disp)
that passes R CMD Check?
Let me test my fledgling understand of the tidyeval
way to do things now:
my_var <- quo(silly)
mutate(mtcars, !!my_var := mpg + disp)
That doesn't work:
hello <- function() {
my_var <- quo(silly)
mutate(mtcars, !!my_var := mpg + disp)
}
´´´
checking R code for possible problems ... NOTE
hello: no visible binding for global variable ‘silly’
hello: no visible binding for global variable ‘mpg’
hello: no visible binding for global variable ‘disp’
I don't know about R CMD CHECK, but Jake's code works with my_var = "silly"
. We're just looking at a variable name here, so it should not need to be evaluated.
For NSE, it looks like quo_name
works:
f = function(v){
v = quo_name(quo(v))
mutate(mtcars, !!v := mpg + disp)
}
f(silly)
The point is that I don't need to pass the variable names as arguments. silly
, mpg
and disp
are hard coded names. So mutate(mtcars, silly = mpg + disp)
would be sufficient but R CMD Check complains that they are global variables. The old solution was mutate_(mtcars, silly = ~ mpg + disp)
. I'm wondering what the tidyeval solution would be. I have the feeling the tidyeval focusses on passing variable names but I need constant names.
You need to use a pronoun:
mutate(mtcars, silly = .data$mpg + .data$disp)
And then import .data
from rlang.
The tidyeval version seems great when you need to pass variable names. But it seems tedious in case of fixed variable names. I find the underscore versions easier and more readable for such cases. I hope those functions remain available.
They have been soft-deprecated and will go away in the long-term. They are convenient but the semantics are not great, and while using ~
protects you against R CMD CHECK notes, they don't actually resolve any ambiguity.
This is nature of programming with dplyr and similar - you lose a lot of the advantages in favour of informative error messages.
I think the better long term plan is to enable R to know about quoting functions. R CMD check should not analyse the calls of such functions. In the meantime if you're writing a package and don't want to use the .data
pronoun it's easy to maintain a list of global variables with utils::globalVariables()
, even though it feels like you shouldn't need to.