`ifelse(test, yes, no)` "should" *not* evaluate `no` when `test` is TRUE, nor `yes` when it is FALSE (as `base::ifelse()` does)

[mmaechler]

The help file of (base R) ifelse has

 Details:

     If ‘yes’ or ‘no’ are too short, their elements are recycled.
     ‘yes’ will be evaluated if and only if any element of ‘test’ is
     true, and analogously for ‘no’.

and of course that is a nice property ("inherited" from R's if(test) yes else no).
However, (in a clean R --vanilla) :

> requireNamespace("ifelse")
> ifelse::.ifelse1(FALSE, 1/foo.bar, "no")
Error: object 'foo.bar' not found
> ifelse::ifelse1(FALSE, 1/foo.bar, "no")
Error: object 'foo.bar' not found

> base::ifelse(FALSE, 1/foo.bar, "no")
[1] "no"

Note that (the "Details: <property>" above) even applies to the case where test is longer than 1.

I think it would make sense if ifelse1() would also fulfill this property,
even though it makes sense for efficiency that it currently applies is.object(.) and sometimes length() very early to these in order to shortcut computation.

I still think it is worth to at least thinking to fulfill this
(in order for me to recommend using it "by default" instead of the current (base R) ifelse()). Or do you think this to be too hard be fulfillable when we simultaneously want the nice properties and behaviour of ifelse1 ?
Slightly weaker (and even more desirable) would be to fulfill at least in the simple cases test = FALSE or test = TRUE (and hence also test = NA) .. that could relatively easily be added, AFAICS.

[jaganmn]

It is precisely this behaviour of ifelse (non-evaluation) that people did not like. My impression is that people would much prefer that the type and attributes of the return value of ifelse1 are determined consistently (hence by evaluating and reconciling all arguments) than that ifelse1 is as efficient as possible.

My thinking was that we would continue to recommend if ... else over ifelse/ifelse1 for the simplest case.

[jaganmn]

Sadly, I had accidentally unsubscribed from GitHub notifications since July, so I am not seeing any of these issues until now ...