Issue #17000 has been updated by nagachika (Tomoyuki Chikanaga).


I understand the pain point discussion of warning for the 3.0 keyword arguments, and I agree to turn off the warning for keyword arguments in ruby_2_7 branch.

But the proposed changesets in the pull request https://github.com/ruby/ruby/pull/3273 turns off the whole deprecated warnings. I worried about a kind of discontinuity of the some deprecation warnings.  For example, IO#lines (and IO#charse, IO#bytes) has been deprecated for the long time, and displayed warning message without any options in 2.6.x and 2.7.1. The warning for IO#lines be disabled by default if the proposed changesets are applied into ruby_2_7.
On the other hand, the warning categories feature (https://bugs.ruby-lang.org/issues/16420) was introduced at 2.7.0. Some long standing deprecated warnings are categorized as "deprecated" class and can be controlled by -W:no-deprecated option or Warning[:deprecated]= method after 2.7.0.

I propose to introduce the dependent category for "keyword arguments" to controll warnings for the 3.0 keyword arguments and backport it into the ruby_2_7 branch.

I think introducing the new warning category has less impacto for compatibility than changing the deprecated warning default behavior. I did a rough search in GitHub and didn't find any code contains `Warning[:depcated]` or option -W:depracated. Maybe my query for the search was wrong and overlook for the real usecase. Please tell me if you find the real application/libraries already using warning categories feature.

----------------------------------------
Feature #17000: 2.7.2 turns off deprecation warnings by deafult
https://bugs.ruby-lang.org/issues/17000#change-86378

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
* Assignee: nagachika (Tomoyuki Chikanaga)
----------------------------------------
Matz has decided to disable deprecation warnings for 3.0 keyword separation by default because many users feel them noisy and painful rather than useful.  See https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argument-pain-point/74980/47 .

https://github.com/ruby/ruby/pull/3273 is a pull request for the change.  It is essentially one-line change in `error.c`, though it has many changes for tests that checks if the warning is appropriately emitted.

Note that this changeset disables *all* deprecation warnings by default.  The reason why I stop not only keyword-related deprecation warnings but all other ones is because, if we disable only keyword-related deprecation warnings, and if keep other deprecation on by default, it becomes ambiguous what `Warning[:deprecated]` should return.  We considered a new API like `Warning[:keyword_separation_deprecated] = true / false`, but we want to minimize the change because it goes to 2.7 branch.  Fortunately, there are not so many other warnings disabled together; a notable one is `Capturing the given block using Kernel#proc is deprecated; use `&block` instead`, but other warnings are minor, as far as I see.  It is somewhat unfortunate, but matz has already agreed with this direction.

Matz also said in the forum, "we will move on to the new keyword argument behavior in Ruby3.0 as planned".  This violates the traditional convention that "gradually" makes deprecation warnings noisy: deprecated behavior is (1) warned only when VERBOSE is enabled, (2) always warned, and (3) removed.  However, matz made this decision due to special circumstances of 3.0 keyword arguments; delaying the change will be also painful.

Note that, currently, the deprecation convention itself is not changed, so this patch is *not* going to master branch.  We can discuss the deprecation policy change in another ticket, if needed.  Anyway, let this ticket focus on ruby_2_7 branch change.  Please do not discuss the convention change in this ticket.

The final decision is up to 2.7 branch maintainer, @nagachika san, but I hope this change is accepted.

cc/ @jeremyevans0 @eregon @nobu @nagachika



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