ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: akr@fsij.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:99251] [Ruby master Feature#16345] Don't emit deprecation warnings by default.
Date: Tue, 21 Jul 2020 13:58:58 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-86634.20200721135858.271@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16345.20191112070718.271@ruby-lang.org

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


matz (Yukihiro Matsumoto) wrote in #note-46:

> So I changed my mind. Deprecation warnings should be turned on manually (probably with `-Wdeprecate` or `Waning[:deprecated]=true`).

I'm glad to hear that.

I still think deprecation warnings should not be emitted by default.


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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

  parent reply	other threads:[~2020-07-21 13:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-16345.20191112070718.271@ruby-lang.org>
2020-07-20  4:59 ` [ruby-core:99232] [Ruby master Feature#16345] Don't emit deprecation warnings by default matz
2020-07-21 13:58 ` akr [this message]
2020-07-27 23:36 ` [ruby-core:99363] " mame
2020-07-28  0:29 ` [ruby-core:99364] " marcandre-ruby-core
2020-07-30  1:39 ` [ruby-core:99398] " ko1
2020-08-24 17:42 ` [ruby-core:99685] " akr
2020-08-26  6:02 ` [ruby-core:99695] " ko1
2020-08-31  5:36 ` [ruby-core:99783] " matz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-86634.20200721135858.271@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).