Saw this the other day:
let()was deliberately designed for a single real-world use case: working with data when you don’t know the column names when you are writing the code (i.e., the column names will come later in a variable). We can re-phrase that as: there is deliberately less to learn as
let()is adapted to a need (instead of one having to adapt to
Rcommunity already has months of experience confirming
let()working reliably in production while interacting with a number of different packages.
let()will continue to be a very specific, consistent, reliable, and relevant tool even after
dpyr 0.6.*is released, and the community gains experience with
tidyeval is your thing, by all means please use and teach it. But please continue to consider also using
wrapr::let(). If you are trying to get something done quickly, or trying to share work with others: a “deeper theory” may not be the best choice.
An example follows. Continue reading In defense of wrapr::let()