A package with only one function, what a concept! But then it becomes tempting to also create a function like if_else_else() and if_else_default() and of course if_not_else() ....
Joking aside, plenty of functionality in extendible languages like R were written long enough ago that they might be done quite differently today. I don't mean just different code, but different arguments it takes and different defaults. Who really wanted you to type stringsAsFactors=TRUE every time, for example. But it is late enough that making changes now can backfire. Look at the announcement that updating ggplot2 to use S7 objects will break some packages that depend on it including many in the Bioconductor world. I would imagine if R magically had started with S7 and skipped over S3 and S4 and perhaps others that have not been widely used, we might have had more consistency. But that is not how it happened and we likely will be stuck for a long time with both R core and all kinds of packages needing to be able to handle older kinds of objects. And, not to compare, but a language like python made a very different approach to objects long ago so that pretty much everything is an object and there generally is no need to create a new form as you can use all kinds of existing ways to tailor your objects to your needs. Given the budgets and other constraints we are dealing with, I suspect that there is a long list of possible changes that are currently not being seriously considered and since there are several work-arounds available in existing packages, there is less urgency. And, there is a reality that although an ifelse() has a certain generality, for specific purposes, it may be trivial enough to fashion your own variant using anything from explicit to implicit loops. But, certainly, if some people work on a variant and show it is compatible and benchmarks suggesting how much faster, then a minimal package with no odd dependencies is a way to go, and might eventually be taken into the core. I would be cautious about naming the package/function as whatever is chosen, ... Avi (too) -----Original Message----- From: R-devel <r-devel-boun...@r-project.org> On Behalf Of Duncan Murdoch Sent: Tuesday, July 8, 2025 3:06 PM To: Josiah Parry <josiah.pa...@gmail.com>; Avraham Adler <avraham.ad...@gmail.com> Cc: r-devel@r-project.org Subject: Re: [Rd] Time to revisit ifelse ? Since you and Antoine are volunteering to do the work, why not start in the way I suggested? Write up a comparison of the known ifelse implementations, and either pick the best one, or choose the best parts of each. Put the result in a package containing nothing else, and invite comment from the wider community. My only comment in advance is that the package should have no dependencies other than base packages, for two reasons: 1. The hope is to have it adopted in base R, and for that it can't have any other dependencies. 2. If it's never adopted by R Core, I might still want to use it, but I don't want to add extra dependencies for just one little function. Duncan Murdoch On 2025-07-08 12:46 p.m., Josiah Parry wrote: > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
