Issue #16345 has been updated by shyouhei (Shyouhei Urabe).


Re: "Don't emit deprecation warnings by default" part of this proposal

I'm for this.  The idea is that while we (ruby-core devs) want people to write new codes, that is not always possible by them... There are gems.

Today, it is almost always the case that a ruby application consists of many 3rd party gems which are out of control of the author of the application.  When a new ruby version issues millions of warnings inside of a gem because the code inside is "deprecated", that is a very huge drawback for the application author to move to new ruby.  The gem is (despite old) proven to work.  The new ruby version is just adding annoyance, and not field-proven.  There is no reason to move.  THIS IS VERY BAD.

Of course, the deprecated features would disappear someday.  Application authors have to brace the impact.  ONLY WHEN they are ready to do so, the deprecation warnings then make sense.  So the timing those warnings are useful depends on each situation, there should be ways to control enable/disabling them.

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

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