Add map_flat_type functions

[cderv]

This closes #405 by bringing back old flatmap() as suggested map_flat_type function.

This PR adds

• map_flat() is equivalent to map() followed by flatten()

• map_flat_lgl(), map_flat_int(), map_flap_dbl(), map_flat_chr() and map_flat_raw are equivalent to map() followed respectively by flatten_lgl(), flatten_int() , flatten_dbl(), flatten_chr() and flatten_raw()

• map_flat_dfr() and map_flat_dfc() is equivalent to [map()] followed respectively by flatten_dfr() and flatten_dfc()

It includes tests.

I will add a NEWS bullet when everything is ok.

[jennybc]

This seems like an area where it would be a good idea to deliberately consider what's going on with (inner) names. I have no specific point -- just that it should be sanity checked and, probably, recorded in the tests.

[jennybc]

Also, from a usage point of view, would be good to come to an understanding of how this relates to unnesting a list-column. Again, I have no particular objection, I just think this PR would be a good occasion to think through this out loud. Perhaps it would lead to a few sentences in the help re: when to use one vs the other and/or an example.

[cderv]

This seems like an area where it would be a good idea to deliberately consider what's going on with (inner) names. I have no specific point -- just that it should be sanity checked and, probably, recorded in the tests.

Unfortunately, I am not sure to see what you mean. Is it to check behavior with named list ?

Also, from a usage point of view, would be good to come to an understanding of how this relates to unnesting a list-column.

I tried to come up with a few examples in a gist. It feels like some very specific ones as main advantage is to flatten list with non-equal length element. That don't come very often when you work with tibble doing some rectangling. For that, you often want to keep list column so map_type functions seems to be enough, as you will flatten afterwards when needed and with tidyr::unnest.

The examples I came up were inspired from several nested list questions, and rectangling task.
I will find others as I relate to this map then flatten question but need to make my use case public and simpler. Aim is to fuel the discussion to think this through.

I agree on this : It needs some work to come up with a good and simple example on when to use one vs the other

I must add that I did not open the issue but just saw the help wanted badge. So I do not have the why old flatmap as to make a come back as map_flat although I find useful.

Notes about gist and reprex

Code used to post the reprex of this gist:

callr::r(function() {
  gistr::gist_create("map_flat_use_case.R", description = "map_flat usage examples", 
                     knit = TRUE, include_source = TRUE)
}, show = TRUE)

One idea would be to be able to post as a gist a reproductible example made with reprex. I used gistr::gist_create here that can render a R file with knit and rmarkdown file then post the source file and the rendered one in the same gist. This could be very useful to do this from reprex, posting the files needed to re execute it. For long reprex, it could be a useful feature. If the idea seems interesting good to you, I may try some implementation to see how it could work. If not in reprex 📦 , this kind of new feature could be link to gistfo 📦 too.

[jennybc]

Unfortunately, I am not sure to see what you mean. Is it to check behavior with named list ?

I meant: what if the list components have inner names? What happens to them? So staring at examples like this and making a deliberate choice re: name handling for the flat maps:

library(purrr)
x <- list(
  a = set_names(letters[1:3]),
  b = set_names(1:3),
  c = set_names(3:1, letters[3:1])
)
unlist(x)
#> a.a a.b a.c b.1 b.2 b.3 c.c c.b c.a 
#> "a" "b" "c" "1" "2" "3" "3" "2" "1"
flatten_chr(x)
#>   a   b   c   1   2   3   c   b   a 
#> "a" "b" "c" "1" "2" "3" "3" "2" "1"

Do you want to open an issue about the gist <--> reprex thing in reprex? I've also wanted to fling one up on the internet easily, e.g. as a gist.

[cderv]

I think #525 contributes to the thinking about flattening and inner names. It could be a solution, or a way to implement a deliberate choice. Looks to me the two are indeed related.

[hadley]

We need to think about this API in light of vctrs; I suspect rather than suffixes we'll need a .type argument.

[hadley]

Thanks for working on this! I'm going to close this PR in recognition that nothing has happened for ~4 years, and we're likely to take a somewhat different approach inspired by vctrs.

[cderv]

Sure no problem ! Thanks 😉