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


sam.saffron (Sam Saffron) wrote:
> I agree 100% with akr here.
> 
> Even with @Eregon's proposed patch running our test suite with warnings is unusable cause of pages of: 

Note that the vast majority of the warnings listed are not keyword argument separation warnings, they are safe level and String#match? warnings.  I think the patch you are using only handles keyword argument separation warnings.  If you extended the approach to other deprecation warnings, which would dedup the warnings, you end up with:

```
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/actionpack-6.0.1/lib/action_controller/metal/request_forgery_protection.rb:285: warning: given argument is nil; this will raise a Typ
eError in the next release
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/activerecord-6.0.1/lib/active_record/connection_adapters/postgresql_adapter.rb:620: warning: given argument is nil; this will raise a
 TypeError in the next release
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/ffi-1.10.0/lib/ffi/pointer.rb:97: warning: rb_safe_level will be removed in Ruby 3.0
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/sassc-2.0.1/lib/sassc/engine.rb:29: warning: rb_safe_level will be removed in Ruby 3.0
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/sassc-2.0.1/lib/sassc/engine.rb:31: warning: rb_safe_level will be removed in Ruby 3.0
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/sassc-2.0.1/lib/sassc/engine.rb:34: warning: rb_safe_level will be removed in Ruby 3.0
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/sassc-2.0.1/lib/sassc/functions_handler.rb:33: warning: rb_safe_level will be removed in Ruby 3.0
/home/sam/.rbenv/versions/trunk/lib/ruby/gems/2.7.0/gems/sassc-2.0.1/lib/sassc/import_handler.rb:43: warning: rb_safe_level will be removed in Ruby 3.0
```

That looks pretty manageable, don't you think?  I think that list is far better than hiding by default.

> I know Jeremy is not keen on this, but tracking callsites is a memory leak and I guess if you wanted to twist my arm hard I could go with warn on first instance EVER. 

Tracking callsites can be a memory leak if your callsites are transient (i.e. there is no fixed bound to them).  That's an unusual case, though.  Do you have an example of a Ruby application where this would cause an actual memory leak (unbounded memory growth)?

> ```
> Warning.enable(:deprecated, :once)
> ```
> 
> Where this means we only warn one time per "type" of deprecation, it outputs to STDERR then sets a bool to say, don't warn again from here. Technically with "first time ever" a developer could still pick up on every deprecation.

True, it just takes more test runs, as each test run will only uncover a single issue.  I'm not against `:once` reporting as an option, but I don't think it is a good default.

akr (Akira Tanaka) wrote:
> 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.

Agreed, warning messages can be frustrating.  However, it is much more frustrating if something stops working completely, which is the likely outcome in Ruby 3.0 of hiding deprecation warnings by default in 2.7.

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

Disabling deprecation warnings by default just delays the pressure till 3.0.  Then the pressure will be even greater, since instead of just displaying warnings, the software will stop working completely.

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

If irb is used, we can know that and change warning behavior.  However, many developers use pry, so changing warning behavior just in irb is not a solution as those developers will not see the warnings.

Likewise, if a test library from stdlib is used, we could know that and change warning behavior.  However, many developers use other test libraries, so changing warning behavior just in test libraries in stdlib is not a solution as those developers will not see the warnings.

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

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