stopifnot() does not stop at first non-TRUE argument

Not sure why the performance penalty of nonstandard evaluation would
be more of a concern here than for something like switch().

If that can't/won't be fixed, what about fixing the man page so it's
in sync with the current behavior?

Thanks,
H.

On 05/03/2017 02:26 AM, peter dalgaard wrote:

The first line of stopifnot is

    n <- length(ll <- list(...))

which takes ALL arguments and forms a list of them. This implies
evaluation, so explains the effect that you see.

To do it differently, you would have to do something like

   dots <- match.call(expand.dots=FALSE)$...

and then explicitly evaluate each argument in turn in the caller
frame. This amount of nonstandard evaluation sounds like it would
incur a performance penalty, which could be undesirable.

If you want to enforce the order of evaluation, there is always

   stopifnot(A)
   stopifnot(B)

-pd

On 3 May 2017, at 02:50 , Herv? Pag?s <hpages at fredhutch.org> wrote:

Hi,

It's surprising that stopifnot() keeps evaluating its arguments after
it reaches the first one that is not TRUE:

 > stopifnot(3 == 5, as.integer(2^32), a <- 12)

 Error: 3 == 5 is not TRUE
 In addition: Warning message:
 In stopifnot(3 == 5, as.integer(2^32), a <- 12) :
   NAs introduced by coercion to integer range

 > a

 [1] 12

The details section in its man page actually suggests that it should
stop at the first non-TRUE argument:

 ?stopifnot(A, B)? is conceptually equivalent to

  { if(any(is.na(A)) || !all(A)) stop(...);
    if(any(is.na(B)) || !all(B)) stop(...) }

Best,
H.

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319