Davis Vaughan

@jennybc I feel like an example of this pattern would be useful in the docs

Two very related PRs: - Unifying the implementation of `.keep` for `mutate()` https://github.com/tidyverse/dplyr/pull/6035 - Which then affected `transmute()`, so we gave it its own separate implementation here https://github.com/tidyverse/dplyr/issues/6086 Extremely important...

I've refreshed myself on the logic in https://github.com/tidyverse/dplyr/pull/6035#issue-1012288146, and I am confident that the current implementation of `mutate(.keep = )` with its current 4 variants is correct. A key principle...

- `group_by()` creates a fundamentally different type of data structure, and we have no way of knowing if it is compatible with your class, so we have to drop it....

The `!!` forces `cur_column()` to be evaluated immediately, even before the `mutate()` call. This is a known limitation that we don't have a great solution for right now, but this...

FWIW this happens in dplyr 1.0.10 and looks to have happened since at least 2020, so I don't consider this an immediate regression. And I'm not 100% it is a...

A bit more information. It looks like `dplyr_reconstruct()`'s default behavior isn't great for data.tables ``` r library(data.table) library(dplyr, warn.conflicts = FALSE) data $names #> [1] "var1" #> #> $row.names #>...

Slightly more minimal reprex, seems to be some kind of issue with the outer and inner group information in combination with our warning handler ``` r library(dplyr, warn.conflicts = FALSE)...

Or, since we don't really promote `.data$` and `.env$` that much, maybe we can take inspiration from `any_of()` / `all_of()` and have a custom helper that `join_by()` knows about that...

@williamlai2 I think the current behavior is right for _most_ people, so I doubt we'd want to add a warning by default for something that people typically expect to happen