lead/lag inside mutate: doesn't accept single-element vector as default value

[kleinschmidt]

When using lead or lag inside mutate, setting default as a length-one vector results in an error:

mutate(data_frame(x = 1:3), lead(x, default = x[1]))
#> Error: expecting a single value

This happens even when the vector isn't a slice of the data frame column:

mutate(data_frame(x = 1:3), lead(x, default = 1))
#> Source: local data frame [3 x 2]
#> 
#>       x lead(x, default = 1)
#>   (int)                (int)
#> 1     1                    2
#> 2     2                    3
#> 3     3                    1
mutate(data_frame(x = 1:3), lead(x, default = c(1)))
#> Error: expecting a single value

And it doesn't happen outside mutate:

x <- 1:3
lead(x, default = x[1])
#> [1] 2 3 1
lead(x, default = c(1))
#> [1] 2 3 1

Also fine when you assign the first element of the vector to a variable first:

d <- data_frame(x = 1:3)
dx1 <- d$x[1]
mutate(d, lead(x, default = dx1))
#> Source: local data frame [3 x 2]
#> 
#>       x lead(x, default = dx1)
#>   (int)                  (int)
#> 1     1                      2
#> 2     2                      3
#> 3     3                      1

If I'm not mistaken, this started happening after upgrading to 0.4.3. (I had code that relied on this behavior that started erroring after upgrading). For what it's worth, the reason I want to do this at all is to do a wrapped lead/lag separately for different subsets of rows in a data frame. So the desired behavior (which was working before the upgrade) is:

data_frame(x = rep(1:2, each = 3), y = 1:6) %>% 
    group_by(x) %>% 
    mutate(y_wrapped = lead(y, default = first(y)))
#> Source: local data frame [6 x 3]
#> Groups: x [2]
#> 
#>       x     y y_wrapped
#>   (int) (int)     (int)
#> 1     1     1         2
#> 2     1     2         3
#> 3     1     3         1
#> 4     2     4         5
#> 5     2     5         6
#> 6     2     6         4

sessionInfo()
#> R version 3.1.2 (2014-10-31)
#> Platform: x86_64-apple-darwin13.4.0 (64-bit)
#> 
#> locale:
#> [1] C
#> 
#> attached base packages:
#> [1] stats     graphics  grDevices utils     datasets  methods   base     
#> 
#> other attached packages:
#> [1] reprex_0.0.0.9001 devtools_1.9.1    dplyr_0.4.3      
#> 
#> loaded via a namespace (and not attached):
#>  [1] DBI_0.3.1       R6_2.1.1        Rcpp_0.12.1     assertthat_0.1 
#>  [5] clipr_0.1.1     compiler_3.1.2  curl_0.9.3      digest_0.6.8   
#>  [9] evaluate_0.7.2  formatR_1.2     htmltools_0.2.6 httr_1.0.0     
#> [13] knitr_1.11      lazyeval_0.1.10 magrittr_1.5    memoise_0.2.1  
#> [17] parallel_3.1.2  rmarkdown_0.8   stringi_0.5-5   stringr_1.0.0  
#> [21] tools_3.1.2

[rickdonnelly]

Sad to see this closed without resolution. Saying that lag "falls back on R evaluation" without elaboration doesn't tell @kleinschmidt anything about how to solve the problem, which is highly frustrating and really limits what I can do with lead and lag. So this is just a permanent bug in dplyr?

[kleinschmidt]

@rickdonnelly, the issue is in fact resolved (see the tests that e214ed3 adds); the examples I posted work as desired on mater. Just hasn't made it into a release yet.