Issue #16345 has been updated by jeremyevans0 (Jeremy Evans).


I'm fine with `Warning.disable(:deprecated)` and similar methods.  Those are nice as they open the door to disabling other warnings, such as method redefinition and uninitialized instance variables.

I'm against not emitting deprecation warnings by default.  That makes them borderline useless, and not worth the effort to implement them at that point.

What people should understand is that at least for keyword arguments (not sure about other deprecation), Ruby goes out of the way to notify you for all places where behavior will change in 3.0 (or whatever version we decide to make the change in).  A huge portion of the difficulty in implementing the keyword argument changes was for proper deprecation warnings.  Not displaying them by default is wasting a huge amount of effort.

If an application generates 2 million warnings on Ruby 2.7, that's a huge indication that it needs to be updated, and should not be run in production until it has been updated so it runs without warnings.  If you are running an old/stable gem and it implements any deprecation warnings, those are indications that it needs to be fixed and it should not be run in production on Ruby 2.7 until the warnings are fixed.

I think we should have the warnings on by default, and be very visible, so the problems they identify get fixed.  Basically, the current behavior is best.  It's better to fix the problems sooner than later. If the warnings are hidden, the problems will take longer to fix, and that hurts the community more than it helps, IMO.  We should push developers and gem maintainers to update their code sooner rather than later.

----------------------------------------
Feature #16345: Don't emit deprecation warnings by default.
https://bugs.ruby-lang.org/issues/16345#change-82660

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
We propose that Ruby doesn't emit deprecation warnings by default.

Deprecation warnings are only useful during development for updating Ruby version.
They are not useful during development with current Ruby.
It is especially frustrating when deprecated warnings are generated in gems.
Also, deprecation warnings are totally useless in production environment.

So, we want to emit deprecation warnings only in useful situations.

We propose a command line argument `-W:deprecated` (or `--warning=deprecated`)
and the following methods to enable/disable deprecation warnings.

```ruby
Warning.disable(:deprecated)
Warning.enable(:deprecated)
Warning.enabled?(:deprecated)
```

Currently we don't propose a method to generate a deprecation warning
because currently our main intent is to disable deprecation warnings for 
keyword arguments, and the warnings are generated in C level.

Background:

We talked about keyword arguments during a developer meeting (2019-11-12).
https://bugs.ruby-lang.org/issues/16333
We expect many deprecation warnings to be generated in Ruby 2.7.
They are not useful except for development for Ruby transition, and
they may block transition to Ruby 2.7.

So, we have consensus to disable deprecation warnings by default.
Our design is intentionally minimum because we need this feature for Ruby 2.7.

We chose `Warning.disable(:deprecated)` instead of
re-defining `Warning.warn` in order to avoid string object generation.

Of course, we expect to extend this feature:
Ruby-level deprecation warning generation,
warnings other than deprecation, 
file-based restriction of warning generation, etc.
But this issue doesn't contain them.




-- 
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>