Refactor capture of arguments #218
Conversation
The latter is not appropriate here because it's a multi-line deparser for arbitrary expressions. Symbols should be cast to strings with `as.character()` or `as_string()`.
The latter is problematic because it allows arbitrary expressions. These variables are forwarded to select(), so potential expressions are `starts_with()`, `one_of()`, etc. The naniar code generally assumes that only symbols are passed in dots. `ensyms()` is a way of ensuring the input types.
|
hmm, I think we can do better by calling into |
|
Thank you very much for this! :) Is there a deadline for getting this fixed and onto CRAN so that revdep for rlang passes? Happy to help move things along with a patch release. |
|
I think I'll revert the changes to |
|
Hiya @lionel- , I just wanted to check if I should merge this and submit a patch release for naniar? |
|
Hmm yes good idea, I was busy lately sorry. IIRC naniar is not compatible with rlang devel because it assumes |
|
OK great, I'll merge this now, thank you again! :) It sounds like there will be some changes to tidyselect in the future WRT quasiquotation? |
Pass
...directly to other functions rather than quote and splice.Use
as_string()rather thanexpr_text()to cast symbols to strings. The latter is a multi-line deparser for arbitrary expressions. It might add backticks to deparsed symbols and allow unwanted input types like complex expressions.Use
ensyms()before coercing to strings. This guarantees only symbols can be passed by user.quos()allows stuff likestarts_with(), but the code generally assumes symbols, not calls.Remove
bare_to_chr()as part of this refactoring. It was making the assumption thatexprs()unwraps quosures, which was a bug in rlang. This causes a revdep failure for the upcoming rlang 0.3.0.