Inconsistent handling of compound assignment pipe operator

[peterdesmet]

Note: this was reported in July 2016 as a dplyr bug by @dkassler at https://github.com/tidyverse/dplyr/issues/2014. @hadley suggested to file it here as a magrittr bug. Could not find bug report (and I'm running into the same problem), so here it is.

When magrittr's compound assignment pipe-operator (%<>%) is used as part of a dplyr pipeline it works even if magrittr itself isn't attached.

library(dplyr)
x <- 1:4
x %<>% `+`(1) %>% mean
x
## [1] 3.5

But if the %<>% operator is the only operator in the pipeline and magrittr hasn't been attached, it results in an error:

x %<>% mean
## Error: could not find function "%<>%"

Note: same is true for loading library(tidyverse) without explicitly loading library(magrittr)

This is easy to resolve on the user end (by simply attaching magrittr in addition to dplyr), but can lead to some confusing behavior if you aren't expecting it. Might it make more sense to export %<>% from dplyr to avoid this inconsistency?

Session info ---------------------------------------------------------------------------------------------------
 setting  value                       
 version  R version 3.2.5 (2016-04-14)
 system   x86_64, mingw32             
 ui       RStudio (0.99.893)          
 language (EN)                        
 collate  English_United States.1252  
 tz       America/New_York            
 date     2016-07-11                  

Packages -------------------------------------------------------------------------------------------------------
 package       * version date       source        
 devtools        1.11.1  2016-04-21 CRAN (R 3.2.5)
 digest          0.6.9   2016-01-08 CRAN (R 3.2.5)
 memoise         1.0.0   2016-01-29 CRAN (R 3.2.5)
 RevoUtilsMath * 3.2.5   2016-05-03 local         
 withr           1.0.1   2016-02-04 CRAN (R 3.2.5)

[hadley]

The bug is that it works anywhere - it suggests something is wrong with the environment that magrittr is evaluating the code in.

[stefanbache]

It is because the pipes are not evaluated sequentially/individually for effeciency, but rather the pipeline is "compiled" and treated as one function. Each of the magrittr pipes are technically the same, except for their name. Therefore, as long as the first pipe being evaluated (the last in the chain) is known in the calling environment, it will know what to do. This "problem" is not unique to %<>% but applies to %T>% and %$% too.

[hadley]

I think this will be fixed as part of the simplified branch, we'll just need to make sure that function environment uses the calling environment of the pipe.

[joshua-theisen]

thanks for the great packages. this issue still exists.