[Rd] transform.data.frame() ignores unnamed arguments when no named argument is provided

[Ben Bolker]

   For what it's worth I think the increased emphasis on classed
errors should help with this (i.e., it will be easier to filter out
errors you know are false positives/irrelevant for your use case).

On Fri, Mar 3, 2023 at 12:17 PM Antoine Fabri <antoine.fabri using gmail.com> wrote:
>
> Let me expand a bit, I might have expressed myself poorly.
>
>  If there is a good reason for a warning I want a warning, and because I
> take them seriously I don't want my console cluttered with those that can
> be avoided. I strongly believe we should strive to make our code silent,
> and I like my console to tell me only what I need to know. In my opinion
> many warnings would be better designed as errors, sometimes with an
> argument to opt in the behaviour, or a documented way to work around. Some
> other warnings should just be documented behavior, because the behavior is
> not all that surprising.
>
> Some reasons why I find warnings hard to debug:
> - options(warn = 1) is not always enough to spot the source of the warning
> - options(warn = 2) fails at every warning, including the ones that are not
> interesting to the user and that they may not do anything about, in these
> cases you'll have to find a way to shut off the first to get to the second,
> and if it's packaged code that's not fun.
> - Unlike with errors, traceback() won't help.
> - tryCatch() will help you only if you call it at the right place, assuming
> you've found it.
> - We might also have many harmless warnings triggered through loops and
> hiding important ones.
> - When you are sure that you are OK with your code despite the warning, say
> `as.numeric(c("1", "2", "foo"))`, a workaround might be expensive (here we
> could use regex first to ditch the non numeric strings but who does that)
> so you're tempted to use `suppressWarnings()`, but then you might be
> suppressing other important warnings so you just made your code less safe
> because the developper wanted to make it safer (you might say it's on the
> user but still, we get suboptimal code that was avoidable).
>
> Of course I might miss some approaches that would make my experience of
> debugging warnings more pleasant.
>
> In our precise case I don't find the behavior surprising enough to warrant
> more precious red ink since it's close to what we get with data.frame(),
> and close to what we get with dplyr::mutate() FWIW, so I'd be personally
> happier to have this documented and work silently.
>
> Either way I appreciate you considering the problem.
>
> Thanks,
>
> Antoine
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel