Issue #16345 has been updated by akr (Akira Tanaka).


I still think disabling deprecation warnings is better default.

The warnings are useless for end users of applications written in Ruby.

Consider Ruby 2.7 will be distributed by an OS (such as Debian) and
some gems are not deprecation-warning free.
I expect there are some gems are not updated before a release of the OS.
So, a user of application written in Ruby on such OS will see deprecation warnings
even if the user doesn't know Ruby.
I think it is frustrating situation.

Also, the warnings may be difficult to remove because
such OS may slow to update gems because stability.
This doesn't cause actual problems because the OS controls Ruby version and
applications should work well on Ruby 2.7.
The important thing is working application, 
not removing deprecation warnings.

I agree that disabling deprecation warnings by default makes
less pressure for developers.

However there are several situations that
we can know a user is a developer (who write Ruby code):

* unit test
* irb

In such situation, we can emit deprecation warnings
for developers without frustrating end users.

Note that reducing duplicated warnings is good thing
for developers.
But I don't think it's enough for end users.


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

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