Why do dplyr verbs remove all (non-class) attributes?

[markvanderloo]

I know about class attributes from Issue #719, but I do not understand why other attributes are removed. Preserving them would be more friendly to pkg authors who may wish to invent functions that fit in the pipeline between dplyr verbs, but need their own attributes.

d <- data.frame(a=1:3)
attr(d,"foo") <- "bar"
d %<>% mutate(a=a/2)
attributes(d)$foo

The above gives NULL.

My simputation pkg simply records the attributes at entry and re-adds them in the end. Clearly, dplyr verbs do something like that with the attribute used for grouping. So why not for others?

[hadley]

In short, because we don't know if your attributes are row-wise, col-wise, or object-wise. For example, should filter() preserve the row.names attribute? Clearly not. Dplyr is deliberately conservative to avoid creating an invalid object. I don't think we can change this default without quite a lot of thought (and I'm pretty sure that is already logged in an existing issue)

[hadley]

Related to #3429

[romainfrancois]

Right. Let's close this in favor of #3429. When it is in place perhaps we can issue warnings about attributes that we don't handle and perhaps suggest that they are made part of a class that deals with it.

[markvanderloo]

Sorry for the duplicate issue. But I disagree with @hadley. Will go to #3429 for that.

[romainfrancois]

It's a matter of who is responsible for keeping track of what these attributes mean. The point of #3429 is to give you some control, because dplyr can't make these decisions.

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/