Issue #16699 has been updated by Eregon (Benoit Daloze).


It's also worth noting that changing $VERBOSE is not thread-safe (it's a truly global variable) and might suppress more or less warnings than intended.

----------------------------------------
Feature #16699: Silence/ignore particular warnings from some parts of the code (in a .rb file)
https://bugs.ruby-lang.org/issues/16699#change-84720

* Author: shevegen (Robert A. Heiler)
* Status: Feedback
* Priority: Normal
----------------------------------------
I would like to make it possible to briefly enable or disable particular warnings: those related to modifying a constant or a method.

It is possible to silence a specific warning as in:

    SOME_CONSTANT = 42
    old_verbose_value = $VERBOSE
    $VERBOSE = nil
    SOME_CONSTANT = 24
    $VERBOSE = old_verbose_value

I needed to do so to redefine a method. I had to add an instance variable to that method. There are alternatives, e.g. including a module, or subclassing, but I wanted to just redefine the method as is, without incurring a warning message on the command line. The above way to re-assign $VERBOSE works fine. It should be kept. At the same time, though, looking at $variables is not that elegant, and it feels a tiny bit hackish too; plus, it may be useful if ruby users may use a more common idiom for this procedure.

I found out that rails has this:

    https://apidock.com/rails/Kernel/silence_warnings

It may be elegant to have a method, be it in Kernel, or in Warnings, or another particular name (silence_warnings is not a bad name).

There may be more use cases, but I am only thinking about these two use cases.

I refer ONLY to situations where the ruby developer would be aware that a warning would be silenced. I run with -w all the time, but not every warning is equally useful to me.

It may be helpful if you could comment a use case for something like this. It may be also helpful if others comment whether the use case may be useful
or not.

We can only settle for a single short method. Otherwise, the current way would be better.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>