From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 334091F66E for ; Mon, 24 Aug 2020 17:43:07 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id DE4E012099B; Tue, 25 Aug 2020 02:42:32 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id A1600120998 for ; Tue, 25 Aug 2020 02:42:30 +0900 (JST) Received: by filterdrecv-p3las1-c4cf4f4c5-n55tq with SMTP id filterdrecv-p3las1-c4cf4f4c5-n55tq-18-5F43FC22-2A 2020-08-24 17:42:58.548634287 +0000 UTC m=+6293.376011170 Received: from herokuapp.com (unknown) by ismtpd0017p1iad2.sendgrid.net (SG) with ESMTP id Az00G--4RPaYNWZZRTAguw for ; Mon, 24 Aug 2020 17:42:58.468 +0000 (UTC) Date: Mon, 24 Aug 2020 17:42:58 +0000 (UTC) From: akr@fsij.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75517 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 16345 X-Redmine-Issue-Author: akr X-Redmine-Sender: akr X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?wr6S=2F0rS9KcpExQc7ATPeOPNOIjnBAThnQXlHCXEyHB54o=2Fg4e8z5YDh9Kb03Z?= =?us-ascii?Q?YgffQ=2F9gKyu8QqHzRuH7vDw46S5uc3wG2rPift2?= =?us-ascii?Q?8uDYFkjIhzkbRCj4jdypjDtGp9IZL6qEu7JW3g3?= =?us-ascii?Q?FYn2j6OFZ5=2FvOqVu6eXpLov8w5I14GFr=2FdgX9gt?= =?us-ascii?Q?TuqXvBRMBYbz1S6KoRA0v8OytICF8z7gdQA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99685 Subject: [ruby-core:99685] [Ruby master Feature#16345] Don't emit deprecation warnings by default. X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16345 has been updated by akr (Akira Tanaka). The enabled-by-default deprecation warnings have following effects. - Good Effect: It makes developers more aware of the problem. (including users noticing and creating a issue) - Bad Effect: Users ignore warnings or stop ruby upgrade Since keyword warnings are so common, these effects are outstanding, but the both effects are not specific to keyword warnings. We can avoid the bad effect and preserve the good effect by disabled-by-default deprecation warnings and changing developer's practice to enable deprecation warnings. The developer's practice can be supported by tools, such as test frameworks enable deprecation warnings automatically. I think two-step migration, disabled-by-default deprecation warnings and enabled-by-default deprecation warnings, is not good idea. It is important that developers can choose timing of dealing incompatibilities. The enabled-by-default deprecation warning forces developers to deal it, so it limits the timing. ---------------------------------------- Feature #16345: Don't emit deprecation warnings by default. https://bugs.ruby-lang.org/issues/16345#change-87173 * 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/