data.frame attributes are preserved on mutate() but dropped on group_by |> mutate

[MilesMcBain]

Reprex:

library(dplyr)
#>
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#>
#>     filter, lag
#> The following objects are masked from 'package:base':
#>
#>     intersect, setdiff, setequal, union
library(purrr)
attr(mtcars, "test") <- "foo"
mtcars_grouped <- group_by(mtcars, cyl)

mtcars |>
  mutate(new_col = 1) |>
  attributes() |>
  pluck("test")
#> [1] "foo"

mtcars_grouped |>
  mutate(new_col = 1) |>
  attributes() |>
  pluck("test")
#> NULL

mtcars_grouped |>
  mutate(across(where(is.complex), as.character)) |>
  attributes() |>
  pluck("test")
#> NULL
# did nothing but still lost attrs on the base data.frame

It would be better if no attributes were lost with mutate. Feels weird in the last case where no mutate actually gets done.

However if group_by() |> mutate() must drop attributes, it's probably better that mutate does also. You can easily get tricked into thinking some code is going to work, but then it bombs when it accidentally gets passed some sticky groups. This happened to me today, 4 levels of package context up from where the mutate was.

[ellessenne]

Hi all,
I see the same issue with a simple mutate() call, where attributes actually get dropped; see for reference: ellessenne/comorbidity#51
Would this be fixed by #6102?
Thanks!

Alessandro

[hadley]

library(dplyr, warn.conflicts = FALSE)
attr(mtcars, "test") <- "foo"

mtcars |>
  mutate(new_col = 1) |>
  attr("test")
#> [1] "foo"

mtcars |>
  mutate(new_col = 1, .by = cyl) |>
  attr("test")
#> [1] "foo"

^{Created on 2022-12-15 with reprex v2.0.2}

[hadley]

Since this problem is resolved by .by, I'm going to close this issue. Fixing it via group_by() is surprisingly challenging because we have to forward attributes into a new data structure, whereas .by completely circumvents the problem because there's no intermediate data structure.

[MilesMcBain]

Maybe not the biggest deal, but this doesn't solve the problem in the original context I mentioned, where a user passes something grouped across an interface boundary.

As an author it'd be nice to be able to write functions that 'just work' within groups or on the whole dataframe as a single group, but things like this mean you have to add special handling code to cater for attributes and groups in combination, AND you also have to know this obscure problem exists to put that code in.

I think it'll continue to catch a small number of people out.

Unless you go full deprecation on group_by in favour of .by. 😝

[MilesMcBain]

Does mutate have enough context to issue a warning it's about to drop the attributes?

[hadley]

In general, I think it's risky to rely on random attributes being magically pass along through any operation. We've done our best to support it in most places in dplyr, but for grouped mutates with random attributes, it doesn't feel to me like the benefit is worth the implementation cost, especially given that there's now an alternative available.

I doubt we can deprecate group_by(), but if .by is successful, I think there's a good chance we'll supersede it.