[Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

[Martin Maechler]

>>>>> Michael Lawrence <lawrence.michael at gene.com>
>>>>>     on Sat, 4 Mar 2017 12:20:45 -0800 writes:

    > Is there really a need for these complications? Packages
    > emitting this warning are broken by definition and should be fixed. 

I agree and probably Henrik, too.

(Others may disagree to some extent .. and find it convenient
 that R does translate 'if(x)'  to  'if(x[1])'  for them albeit
 with a warning .. )

    > Perhaps we could "flip the switch" in a test
    > environment and see how much havoc is wreaked and whether
    > authors are sufficiently responsive?

    > Michael

As we have > 10'000 packages on CRAN alonce,  and people have
started (mis)using suppressWarnings(.) in many places,  there
may be considerably more packages affected than we optimistically assume...

As R core member who would  "flip the switch"  I'd typically then
have to be the one sending an e-mail to all package maintainers
affected.... and in this case I'm very reluctant to volunteer
for that and so, I'd prefer the environment variable where R
core and others can decide how to use it .. for a while .. until
the flip is switched for all.

or have I overlooked an issue?

Martin

    > On Sat, Mar 4, 2017 at 12:04 PM, Martin Maechler
    > <maechler at stat.math.ethz.ch
    >> wrote:

    >> >>>>> Henrik Bengtsson <henrik.bengtsson at gmail.com> >>>>>
    >> on Fri, 3 Mar 2017 10:10:53 -0800 writes:
    >> 
    >> > On Fri, Mar 3, 2017 at 9:55 AM, Hadley Wickham >
    >> <h.wickham at gmail.com> wrote: >>> But, how you propose a
    >> warning-to-error transition >>> should be made without
    >> wreaking havoc?  Just flip the >>> switch in R-devel and
    >> see CRAN and Bioconductor packages >>> break overnight?
    >> Particularly Bioconductor devel might >>> become
    >> non-functional (since at times it requires >>> R-devel).
    >> For my own code / packages, I would be able >>> to handle
    >> such a change, but I'm completely out of >>> control if
    >> one of the package I'm depending on does not >>> provide
    >> a quick fix (with the only option to remove >>> package
    >> tests for those dependencies).
    >> >>
    >> >> Generally, a package can not be on CRAN if it has any
    >> >> warnings, so I don't think this change would have any
    >> >> impact on CRAN packages.  Isn't this also true for >>
    >> bioconductor?
    >> 
    >> > Having a tests/warn.R file with:
    >> 
    >> > warning("boom")
    >> 
    >> > passes through R CMD check --as-cran unnoticed.
    >> 
    >> Yes, indeed.. you are right Henrik that many/most R
    >> warning()s would not produce R CMD check 'WARNING's ..
    >> 
    >> I think Hadley and I fell into the same mental pit of
    >> concluding that such warning()s from
    >> if(<length-larger-one>) ...  would not currently happen
    >> in CRAN / Bioc packages and hence turning them to errors
    >> would not have a direct effect.
    >> 
    >> With your 2nd e-mail of saying that you'd propose such an
    >> option only for a few releases of R you've indeed
    >> clarified your intent to me.  OTOH, I would prefer using
    >> an environment variable (as you've proposed as an
    >> alternative) which is turned "active" at the beginning
    >> only manually or for the "CRAN incoming" checks of the
    >> CRAN team (and bioconductor submission checks?)  and
    >> later for '--as-cran' etc until it eventually becomes the
    >> unconditional behavior of R (and the env.variable is no
    >> longer used).
    >> 
    >> Martin
    >> 
    >> ______________________________________________
    >> R-devel at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> 

    > 	[[alternative HTML version deleted]]