I have to echo this point. It is much easier than the earlier way of doing things. I also like the splicing operators because they save you a lot of busywork with manipulating arguments.
The biggest problem I think is that the framework is hard to learn, because we don’t have many learning resources yet (be they vignettes, tutorials, or packages we can snoop on for ideas) and because the concepts are difficult to talk about. It is a challenge to get up to speed with tidyeval. But the design is an upgrade, and the documentation can always be improved.
One of my stumbling blocks with the tidyeval framework is that I was too quick to jump into quoting/unquoting.
When we’re writing packages and if we want to use to dplyr functions, we have to use rlang in order to quote the names so that CRAN package checks do not wrongly warn about undefined global variables. For a while, I was annoyed because I thought that I had to quote-unquote any bare name used in dplyr function, using code like
s_time <- rlang::sym("time")
mutate(df, time2 = round(!! s_time, 2))
But it turns out that we now have a
.data pronoun, which let’s us skip that step.
mutate(df, time2 = round(.data$time, 2))
Any I’ve started using that in my package code.
My point being that it can be frustrating and tedious because it’s not clear—yet—what the best practices are for using tidyeval, but that’s a manageable problem as the community writes more tutorials, cookbooks and cheatsheets.