Avi, appreciate the puns! I don't think anyone is suggesting R-core dedicate all of their time to this problem. To me, the thread is about consensus making (as there is no formal way to do that).
Quoting OP here: "It's not about asking others to do it really, that was a harsh assumption. I'd be happy to propose a version if it helps, I'd be also very happy if it were just a copy of if_else or fifelse (both MIT FWIW)." The initial email, IMO, was to show that there already are community implementations of faster and type-safer of ifelse (notably dplyr and data.table and I'd add kit::iif, too) and perhaps now is the time to add this enhancement to the language. It is tough to get a sense of total usage of each though but some code searching on GitHub: - data.table::fifelse: https://github.com/search?q=%22fifelse%28%22+language%3AR&type=code - dplyr::if_else: https://github.com/search?q=%22if_else%28%22+language%3AR&type=code - kit::iif: https://github.com/search?q=%2F%28%3F-i%29iif%5C%28%2F+language%3AR+&type=code On Tue, Jul 8, 2025 at 8:23 AM Avraham Adler <avraham.ad...@gmail.com> wrote: > On Tue, Jul 8, 2025 at 10:55 AM Josiah Parry <josiah.pa...@gmail.com> > wrote: > > > > I think the point is not that there needs to be a smaller package for yet > > another if-else (https://xkcd.com/927/). It is that if the R-language, > as a > > whole, had a performant if-else in the base of the language would benefit > > **everyone** such that a data.table or dplyr or gtools etc. alternative > > would not be necessary. > > While that may be true, Josiah, R Core's time is very limited. > Following Duncan's idea, if a small, simple package were created and > was proven to dominate the performance of standard ifelse without > causing any issues with the ten thousand plus packages in the R > environment, that would make R Core's decision much simpler, whether > or not to use the existing, proved performant code. Asking R Core to > do the research and testing for something which currently _works_, > albeit not in the most efficient way possible, is pretty much a > non-starter. Do as much work as possible for R Core to have even a > possibility of consideration. For something similar, albeit much less > core (pun intended) to R's code, see this discussion [1] from June > 2012 on Kendall's tau, where the code already existed but was deemed > unimportant enough to add to base R. > > [1] https://stat.ethz.ch/pipermail/r-devel/2012-June/064351.html > > Thanks, > > Avi > > > > > On Tue, Jul 8, 2025 at 5:09 AM Ben Bolker <bbol...@gmail.com> wrote: > > > > > I think Duncan's point is that R-core are (reasonably) very, very, > > > very conservative about adding things to base R. It would be useful to > > > the community, and would indeed further the discussion, to make a tiny > > > package containing just that function. (Even just copying it from some > > > other package might require some work to disentangle it from > > > dependencies: for example, a quick glance at dplyr::if_else shows that > > > it uses functions from rlang, vctrs, ...) > > > > > > I'd be happy to accept a pull request in `gtools`, which is a > > > zero-dependency (except base R) package for small utility functions ... > > > > > > cheers > > > Ben Bolker > > > > > > > > > On 7/8/25 07:36, Antoine Fabri wrote: > > > > It's not about asking others to do it really, that was a harsh > > > assumption. > > > > I'd be happy to propose a version if it helps, I'd be also very > happy if > > > it > > > > were just a copy of if_else or fifelse (both MIT FWIW). > > > > It's a low level building block and it's broken, IMO it's way better > to > > > > have it available and documented in base R and incite everyone to > use it, > > > > so not only we don't suffer from it in the code we write, but also > in the > > > > code we use or inherit from. > > > > > > > > Le mar. 8 juil. 2025 à 13:25, Duncan Murdoch < > murdoch.dun...@gmail.com> > > > a > > > > écrit : > > > > > > > >> Rather than asking others to do this, why don't you create a tiny > > > >> package containing nothing other than an ifelse() replacement? I > > > >> wouldn't want to depend on dplyr or data.table just to get their > > > >> versions, but depending on your tiny package wouldn't be an issue. > > > >> > > > >> Duncan Murdoch > > > >> > > > >> On 2025-07-08 6:12 a.m., Antoine Fabri wrote: > > > >>> Dear r-devel, > > > >>> > > > >>> `ifelse()` has a lot of issues, and for these reasons it has been > > > redone > > > >> in > > > >>> `dplyr::if_else()` and `data.table::fifelse()`, which are both > great. > > > Yet > > > >>> it's an important base R function, it's really hard to program in > base > > > R > > > >>> without it and scores probably as high as it gets in the most_used > * > > > >>> most_problematic metric. > > > >>> > > > >>> Obviously we can't change it without breaking a ton of code, but > with > > > all > > > >>> the experience we now have with it and the dplyr and data.table > > > >> alternative > > > >>> maybe it might not be absurd to have a good alternative, say > `if.else` > > > in > > > >>> base R, that we can document on the same page and recommend for > future > > > >> use. > > > >>> It would require a common type in yes/no, not return logical() for > all > > > >> zero > > > >>> length input, work with dates, datetimes and factors, handle a na > > > >> condition > > > >>> etc. The test suites of dplyr and data.table probably tell us > > > everything > > > >>> about the edge cases we want to look at. Maybe the old ifelse could > > > even > > > >>> warn when called from the top level, to incite us to work with the > new > > > >> one. > > > >>> > > > >>> It feels wrong to me to be stuck with ifelse() forever just > because it > > > >> has > > > >>> been like this for a long time. I'm sure some of you learnt your > way > > > >> around > > > >>> it but I work with R every day and after 10+ years of R it still > bites > > > me > > > >>> all the time, I'm probably not alone, at least chatGPT called it a > > > >>> "footgun", and we don't want that :). > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Antoine > > > >>> > > > >>> [[alternative HTML version deleted]] > > > >>> > > > >>> ______________________________________________ > > > >>> R-devel@r-project.org mailing list > > > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > > > >> > > > >> > > > > > > > > [[alternative HTML version deleted]] > > > > > > > > ______________________________________________ > > > > R-devel@r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > > > Dr. Benjamin Bolker > > > Professor, Mathematics & Statistics and Biology, McMaster University > > > Director, School of Computational Science and Engineering > > > * E-mail is sent at my convenience; I don't expect replies outside of > > > working hours. > > > > > > ______________________________________________ > > > R-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
