Issue #16345 has been updated by sam.saffron (Sam Saffron).


> I'm against not emitting deprecation warnings by default. 

I disagree with this, in this case the enormous amount of complaining hurts the ecosystem applies unneeded urgency on people and causes conflict in the community.

We have been through this previously with secret ENV vars that make Ruby "faster". Forcing people to learn about a magical env var to disable deprecations they have no control over is in the same boat. Besides, this will just end up being reported as a security bug to the security list if left as is, cause docker will eat up all your disk space due to a single call site flooding STDERR forcing logs to grow forever. 

Fixing your own app may be straightforward, in the Discourse case it was just editing a few files, but forcing people to start piling on and pressuring gem authors cause 2.7 is out and now and the gem they released is causing a big pile of warnings and they happen to be on a 3 week break and now they need to hunt down a computer and commit a complex patch cause delegation is now very messy, would not be nice.

We have at least a year here to clean up the mess after 2.7 is released, we don't need an artificial urgency here. I am happy to strive to run Discourse deprecation free as soon as possible, but if a gem author takes 2 months to sort this out this is not a huge deal for me. 

If we must an alternative here is to release a minor of 2.7 say 9 months from now that flicks the default cause the fire is imminent.

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

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