Patches for dplyr type conversions

[dsweber2]

Various functions will convert epi_df's to tibbles. This is to catalog which of those have been fixed/don't need to be fixed

• arrange
• complete
• distinct
• filter
• slice*
• glimpse (doesn't make sense)
• mutate
• pull (doesn't make sense)
• relocate (some design choices to be made)
• rename
• select (PR patch: get select working with grouping #390)
• count, tally, (may not make sense)
• add_count, add_tally
• summarize (doesn't make sense)
• n, cur_group, cur_group_id etc doesn't really make sense
• bind_cols (also doesn't work for ungrouped)
• bind_rows
• intersect, union etc
• inner_join

[dsweber2]

we also need something simliar for epi_archive's. filter for example doesn't work.

[dshemetov]

Related #618

[dshemetov]

We now have filter for epi_archives.

[JavierMtzRdz]

I reviewed the unresolved functions in this list that are neither marked as nonsensical nor discussed elsewhere, as well as other functions I considered relevant. It is worth noting that complete.epi_df is already implemented, so I marked it as completed in the list.
From this, I observed the following behaviour:

• epi_df is preserved in the following cases:
  • relocate: seems to work as expected (via dplyr generic).
  • distinct: seems to work as expected (via dplyr generic).
  • fill: seems to work as expected (tidyr generic preserves class).
• epi_df decays when using:
  • drop_na.
  • pivot_*.

For cases where epi_df is preserved, I do not think further changes are necessary. For the cases that decay, I have added a possible method in the tidyr-met branch. They work as follows:

• drop_na. Always returns an epi_df, as it only subsets rows and does not remove essential key columns.
• pivot_wider.
  • Preserves epi_df if geo_value and time_value columns remain in the output. other_keys metadata is automatically updated to exclude any keys that were pivoted away or removed.
  • Silently decays if geo_value or time_value are used in names_from and thus removed as columns.
• pivot_longer.
  • If the pivot makes the data non-unique on existing keys, the new names_to column is automatically added to other_keys to maintain the uniqueness. If the result is still not unique even after promoting the new key, it issues a warning and decays into a tibble.
  • If geo_value or time_value are pivoted away, the result silently becomes a tibble.

Please inform me if this logic can be improved or if these methods are unnecessary.

Also, do other methods need a review?

[brookslogan]

Re pivot_longer:

If the pivot makes the data non-unique on existing keys, the new names_to column is automatically added to other_keys to maintain the uniqueness. If the result is still not unique even after promoting the new key, it issues a warning and decays into a tibble.

Do you think it'd make more sense to remove "If the pivot makes the data non-unique on existing keys", and just always try to add names_to to other_keys?

Re. other methods to test:

• summarize (think this actually makes sense for aggregating geo x age x time -> geo x time)
• group_split (with special consideration of .keep = TRUE) (this makes sense if user wants to make a more controllable group_modify)
• slice
• slice_* (e.g., user wants to select the last N time values for each geo)
• nest
• unnest (though we're limited in in what we can do with current epi_df design; if we nest away geo or time, then we lose the class and can't recover after unpacking, unless maybe we packed away both at the same time, and the nested df list column contains epi_dfs)
• unnest_*
• rowwise

Lower prio relative to above:

• expand
• chop
• unchop (similar limitations to unnest)
• pack
• unpack (similar limitations to unnest)
• nest_join
• hoist
• unite
• separate
• separate_*