[Rd] attach "warning" is a message

Martin Maechler m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Tue Aug 10 11:50:01 CEST 2021

>>>>> Simon Urbanek 
>>>>>     on Tue, 10 Aug 2021 11:28:19 +1200 writes:

    > Barry,

    > it is not a warning nor plain output, it is a message, so you can use 

    >> d = data.frame(x=1:10)
    >> x=1
    >> suppressMessages(attach(d))

    > Looking at the history, this used to be cat() but got changed to a message in R 3.2.0 (r65385, CCIng Martin in case he remembers the rationale for warning vs message). I don't know for sure why it is not a warning, but I can see that it is more in the line with informative messages (like package masking) as opposed to a warning - in fact the change suggest that the intention was to synchonize both. That said, I guess the two options are to clarify the documentation (also in library()) or change to a warning - not sure what the consequences of the latter would be.

    > Cheers,
    > Simon

Thank you, Simon.
One rationale back then was that  message() *is* in some sense
closer to cat()  than warning() is (and indeed, to synchronize
with the conflict messages from `library(.)` or `require(.)`.
Also, I would say that a message is more appropriate here than a
warning when someone explicitly attach()es something to the
search() path (s)he may get a notice about masking but to be
warned is too strong {warnings being made into errors in some setups}.

So I'd propose to only update the documentation i.e.


    >> On 10/08/2021, at 2:06 AM, Barry Rowlingson <b.rowlingson using lancaster.ac.uk> wrote:
    >> If I mask something via `attach`:
    >>> d = data.frame(x=1:10)
    >>> x=1
    >>> attach(d)
    >> The following object is masked _by_ .GlobalEnv:
    >> x
    >> I get that message. The documentation for `attach` uses the phrase
    >> "warnings", although the message isn't coming from `warning()`:
    >> warn.conflicts: logical.  If ‘TRUE’, warnings are printed about
    >> ‘conflicts’ from attaching the database, unless that database
    >> contains an object ‘.conflicts.OK’.  A conflict is a function
    >> masking a function, or a non-function masking a non-function.
    >> and so you can't trap them with options(warn=...) and so on. This sent me
    >> briefly down the wrong track while trying to figure out why R was showing a
    >> masking error in one context but not another - I wondered if I'd supressed
    >> warning()s in the other context.
    >> Personally I'd like these messages to be coming from warning() since that
    >> seems the appropriate way to warn someone they've done something which
    >> might have unwanted effects. But fixing the documentation to say "If
    >> ‘TRUE’, *messages* are printed" is probably less likely to break existing
    >> code.
    >> Happy to add something to bugzilla if anyone thinks I'm not being overly
    >> pedantic here.
    >> Barry
    >> [[alternative HTML version deleted]]
    >> ______________________________________________
    >> R-devel using r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list