ruby-core

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


In short: yes, warn iff not seen before can be an acceptable option.

jeremyevans0 (Jeremy Evans) wrote:
> The logical conclusion of this reasoning is that no deprecation warnings should ever be added, since any deprecation warning could theoretically cause a problem.

Well if you go extremely strict, you are right.  Any warnings could theoretically cause problems.  And yet, they are OK if explicitly enabled at runtime.  There is a clear intention that a user needs those warnings then.  Not emitting deprecation warnings "by default" is a win.

In practice -- backward compatibility issues are always practices -- what is a "problem" and what is not is very fuzzy.  Millions of lines of warnings flooding the STDERR is clearly troublesome.  But what about only one warning at bootup?  Obviously less.  Maybe acceptable.  Then what about dozens?  Or hundreds?  Or thousands?

Also, because warnings go through Warning.warn, it involves Ruby-level string allocation every time.  Logging a warning to storages involves IO.  These overheads are hard to be admitted during accepting HTTP requests, but maybe not that severe when they show up at bootup and keep silent for the rest of a process lifetime.

> However, I don't think that is a good approach. What are your opinions of not warning at all by default compared to eliminating duplicate warnings or stopping after a certain number of warnings?

So what I think is wrong is those warnings _continuously_ displayed.  I prefer the way requested in this ticket, but #16289 is practically an acceptable solution to me.

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

* 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:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>