You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
... suggesting that it's intended to handle NA values (same for discard()), but it's purrr:::where_if() that's actually throwing the error.
Is this intended?
While I tend to try to opt for explicitness as much as possible, I think the NA-handling as coded in keep() and discard() make sense and align with dplyr::filter()'s logic. I also think that enabling NA-handling as coded again would be backwards compatible, since any existing code must be coercing (or otherwise explicitly-handling) NAs anyhow.
FWIW, the documentation doesn't explicitly mention NA-handling, but states:
for keep: "all elements where .p evaluates to TRUE", which would be valid as coded
for discard: "all elements where .p evaluates to FALSE", which is not exactly valid as coded, as discard()'s definition also retains NAs (if where_if() didn't throw).
Alternatively, adding something like .na = c(TRUE, FALSE) parameter (with match.arg) would be a clear & compact way to make such choices explicit, while removing common coercion cruft in .p.
Cheers!
{purrr} v1.0.2
The text was updated successfully, but these errors were encountered:
I haven't checked previous {purrr} versions to see if this is new(ish) behavior, but for some reason this surprised me:
(Same for
discard()
.)When inspecting
keep()
, however, we see that:... suggesting that it's intended to handle
NA
values (same fordiscard()
), but it'spurrr:::where_if()
that's actually throwing the error.Is this intended?
While I tend to try to opt for explicitness as much as possible, I think the
NA
-handling as coded inkeep()
anddiscard()
make sense and align withdplyr::filter()
's logic. I also think that enablingNA
-handling as coded again would be backwards compatible, since any existing code must be coercing (or otherwise explicitly-handling)NA
s anyhow.FWIW, the documentation doesn't explicitly mention
NA
-handling, but states:keep
: "all elements where.p
evaluates toTRUE
", which would be valid as codeddiscard
: "all elements where.p
evaluates toFALSE
", which is not exactly valid as coded, asdiscard()
's definition also retainsNA
s (ifwhere_if()
didn't throw).Alternatively, adding something like
.na = c(TRUE, FALSE)
parameter (withmatch.arg
) would be a clear & compact way to make such choices explicit, while removing common coercion cruft in.p
.Cheers!
{purrr} v1.0.2
The text was updated successfully, but these errors were encountered: