> If that is right -- and I tend to believe it is right -- this change had > better been done in R core and not on package level. I think the root of > this evil is design inconsistencies of the language together with the lack > of removing these inconsistencies. The longer we hesitated, the more > packages such a change could break. The lack of addressing issues in R core > drives people to try to solve issues on package level. But now we have two > conflicting standards, i.e. a fork-within-the-language: Am I a member of the > tidyverse or not? Am I writing a package for the tidyverse or for standard-R > or for both. With a fork-of-the-language we would at least have a majority > vote for one of the two and only the fitter would survive. But with a > fork-within-the-language 'R' gets more and more complex, and working with it > more and more difficult. There is not only the tidyverse, also the Rcppverse > and I don't know how many other verses. If there is no extinction of > inconsistencies in R, not sufficient evolution in R, but lots of evolution > in Julia, evolution will extinct R together with all its foobarverses in > favor of Julia (or Python). May be that's a good thing.
I think you are making a slippery slope argument, and I'm not sure I buy it. I am quite aware of the danger of introducing additional inconsistencies, and do it very selectively, only when I'm convinced that the pain is worth it. > I think tibble should respect drop=TRUE and respect the work of all package > authors who wrote defensive code and explicitly passed drop= instead of > relying on the (wrong) default We'll consider for the next major release: https://github.com/tidyverse/tibble/issues/311 > . Again: better would be a long-term clean-up > roadmap of R itself and one simple standard called 'data.frame'. Instead of > forking or betting on any particular foobarverse: why not have direct > democratic votes about certain critical features of such a long-term roadmap > in such a big community? I'm not sure that democracy works for programming language design. Hadley -- http://hadley.nz ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel