On 30/08/2018, 20:15, "R-devel on behalf of Hadley Wickham" <r-devel-boun...@r-project.org on behalf of h.wick...@gmail.com> wrote:
On Thu, Aug 30, 2018 at 10:58 AM Martin Maechler <maech...@stat.math.ethz.ch> wrote: > > >>>>> Joris Meys > >>>>> on Thu, 30 Aug 2018 14:48:01 +0200 writes: > > > On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth > > <toth.de...@kogentum.hu> wrote: > >> Note that `||` and `&&` have never been symmetric: > >> > >> TRUE || stop() # returns TRUE stop() || TRUE # returns an > >> error > >> > >> > > Fair point. So the suggestion would be to check whether x > > is of length 1 and whether y is of length 1 only when > > needed. I.e. > > > c(TRUE,FALSE) || TRUE > > > would give an error and > > > TRUE || c(TRUE, FALSE) > > > would pass. > > > Thought about it a bit more, and I can't come up with a > > use case where the first line must pass. So if the short > > circuiting remains and the extra check only gives a small > > performance penalty, adding the error could indeed make > > some bugs more obvious. > > I agree "in theory". > Thank you, Henrik, for bringing it up! > > In practice I think we should start having a warning signalled. > I have checked the source code in the mean time, and the check > is really very cheap > { because it can/should be done after checking isNumber(): so > then we know we have an atomic and can use XLENGTH() } > > > The 0-length case I don't think we should change as I do find > NA (is logical!) to be an appropriate logical answer. Can you explain your reasoning a bit more here? I'd like to understand the general principle, because from my perspective it's more parsimonious to say that the inputs to || and && must be length 1, rather than to say that inputs could be length 0 or length 1, and in the length 0 case they are replaced with NA. Hadley I would say the value NA would cause warnings later on, that are easy to track down, so a return of NA is far less likely to cause problems than an unintended TRUE or FALSE. And I guess there would be some code reliant on 'logical(0) || TRUE' returning TRUE, that wouldn't necessarily be a mistake. But I think it's hard to predict how exactly people are using functions. I personally can't imagine a situation where I'd use || or && outside an if-statement, so I'd rather have the current behaviour, because I'm not sure if I'm reliant on logical(0) || TRUE somewhere in my code (even though that would be ugly code, it's not wrong per se) But I could always rewrite it, so I believe it's more a question of how much would have to be rewritten. Maybe implement it first in devel, to see how many people would complain? Emil Bode ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel