Davis Vaughan

Different from https://github.com/r-lib/funs/issues/42#issue-530151360 because the output size here is `vec_size(.x)` and the output size there is `vec_size(.g)`

I'm not sure this one is a bug. It uses the same principles as this, i.e. that this data frame is treated as a list with 3 elements ``` r...

That should mean we get recycling for `pmap()` too. Maybe a test? Not sure if it is worth repeating similar tests Also, this is another case to maybe use the...

As we've refined these new-ish verbs in the 1.2.0 release (tweaking defaults, adding arguments), it has been extremely helpful that they _aren't_ generic so we don't have to deal with...

Additional notes on upgrading tidyr verbs to use vctrs, and the issues that would solve: - `replace_na()` - PR for this one https://github.com/tidyverse/tidyr/pull/1109 - `drop_na()` - https://github.com/tidyverse/tidyr/issues/906 - `fill()` -...

- `expand()` is `summarize() + crossing()` (and possibly `nesting()`, as needed) - `complete()` is a combination of that with `full_join()` and `replace_na()` ``` r library(tidyr) library(dplyr, warn.conflicts = FALSE) df...

Going from single line to multiline is actually exactly where it changed so maybe that should be relaxed a bit https://github.com/r-lib/vctrs/pull/329#discussion_r283047972

I just found myself wanting to do: ```r predictions

I do like the separation since they both take the same arguments. But I assume we'd get into the same issue if a third or fourth prediction type was added,...

You could always transform the values on the fly ```r df |> pivot_longer(cols = y:z, values_transform = as.list) #> # A tibble: 4 × 3 #> x name value #>...