slice helper error when no n or prop

[eutwt]

For the slice helper functions, would it make sense to move check_slice_dots() from the data.frame methods to the generics? My thought is that dtplyr and dbplyr can rely on it to prevent malformed calls and provide the right error. Right now when n is not provided, dtplyr has an error message that's not as friendly, and dbplyr has different behavior.

library(rlang)
library(glue)
#> Warning: package 'glue' was built under R version 4.1.2
df <- data.frame(a = 1:10)

library(dplyr, warn.conflicts = FALSE)
#> Warning: package 'dplyr' was built under R version 4.1.2

df %>% 
  slice_sample(1)
#> Error in `slice_sample()`:
#> ! `n` must be explicitly named.
#> ℹ Did you mean `slice_sample(n = 1)`?

library(dtplyr)
#> Warning: package 'dtplyr' was built under R version 4.1.2

df %>% 
  lazy_dt() %>% 
  slice_sample(1)
#> Error in `slice_sample()`:
#> ! `...` must be empty.
#> ✖ Problematic argument:
#> • ..1 = 1
#> ℹ Did you forget to name an argument?

library(dbplyr, warn.conflicts = FALSE)
#> Warning: package 'dbplyr' was built under R version 4.1.2

con <- DBI::dbConnect(RSQLite::SQLite(), ":memory:")
copy_to(con, df)
df2 <- tbl(con, "df")

df2 %>% 
  slice_sample(1)
#> # Source:   SQL [1 x 1]
#> # Database: sqlite 3.38.5 [:memory:]
#>       a
#>   <int>
#> 1     6

^{Created on 2022-07-24 by the reprex package (v2.0.1)}

[hadley]

I'm not sure whether or not it's a good idea to put input checking code in the generic or not. My main concern is that this fundamentally limited the scope of the methods. But maybe that's ok here, since we expect methods to always require one of n and prop?