Bring back flatmap #405
Comments
|
If is ok, I can work on this as it is help wanted. Will do a PR shortly. |
Merged
hadley
added a commit
that referenced
this issue
Sep 8, 2022
The key idea is to introduce a new family of "combining" functions: `list_c()`, `list_rbind()`, and `list_cbind()`, which replace `flatten_lgl()`, `flatten_int()`, `flatten_dbl()`, `flatten_chr()` (now `list_c()`), `flatten_dfc()` (`list_cbind()`), and `flatten_dfr()` (`list_rbind()`). The new functions are straightforward wrappers around vctrs functions, but somehow feel natural in purrr to me. This leaves `flatten()`, which had a rather idiosyncratic interface. It's now been replaced by `list_flatten()` which now always removes a single layer of list hierarchy (and nothing else). While working on this I realised that this was actually what `splice()` did, so overall this feels like a major improvement in naming consistency. With those functions in place we can deprecate `map_dfr()` and `map_dfc()` which are actually "flat" map functions because they combine, rather than simplify, the results. They have never actually belonged with `map_int()` and friends because they don't satisfy the invariant `length(map(.x, .f)) == length(.x)`, and `.f` must return a length-1 result. This also strongly implies that `flat_map()` would just be `map_c()` and is thus not necessary. * Fixes #376 by deprecating `map_dfc()` * Fixes #405 by clearly ruling against `map_c()` * Fixes #472 by deprecating `map_dfr()` * Fixes #575 by introducing `list_c()`, `list_rbind()`, and `list_cbind()` * Fixes #757 by deprecating `flatten_dfr()` and `flatten_dfc()` * Fixes #758 by introducing `list_rbind()` and `list_cbind()` * Part of #900
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
as
map_flat_type.The text was updated successfully, but these errors were encountered: