ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: nagachika00@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:99022] [Ruby master Feature#17000] 2.7.2 turns off deprecation warnings by deafult
Date: Thu, 02 Jul 2020 01:00:06 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-86397.20200702010005.18@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17000.20200630115213.18@ruby-lang.org

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


mame (Yusuke Endoh) wrote in #note-3:
> Let me confirm: what do you mean "dependent"?
I'm sorry, I just misspelled it. I mean "new *deprecated* category for keyword arguments".

> Let's call the new category "`:keyword_deprecated`".  `Warning[:deprecated]` is true by default, and `Warning[:keyword_deprecated]` is false by default.  I think that the following behavior is expected:
Thank you for clarifying. The table you show is exactly what I expected.

> Adding a new category means that we need to change not only 2.7 branch but also master branch.  In master, we need to accept (and just ignore) `Warning[:keyword_deprecated] = true`.  We need to get approval from matz.

You are right. I didn't consider about master branch.
In this point, Jeremy's proposal could inspires us.


jeremyevans0 (Jeremy Evans) wrote in #note-4:
> An alternative approach to adding `Warning[:keyword_deprecated]` that would be easier to implement in 2.7 and would not require changes to master would be only printing keyword argument warnings in verbose mode.  This should be a one-line change here: https://github.com/ruby/ruby/blob/ruby_2_7/vm_args.c#L600

I understand your proposal is enabling all warnings in "deprecated" category (keywords and others) only if $VERBOSE=true and `Warning[:deprecated]=true`, is that right?
I rather like to suppress only keyword arguments warning without $VERBOSE=true and don't suppress other deprecated category warning.
I show the another proposal in the following table.
 
| `Warning[:deprecated]` | `$VERBOSE` | other deprecation | keyword deprecation |
|------------------------|--------------------------------|----------------------|---------------------|
| true (default)         | false (default)                | printed              | not printed         |
| true                   | true                           | printed              | printed             |
| false                  | false                          | not printed          | not printed         |
| false                  | true                           | not printed          | not printed             |

I know we have to create more than one line patch for this change, but the implementation bug can be fixed in the next teeny releases.
I'd like to concentrate to consider the good specification which has less impact for users while reduce verbosity for keyword args warning.

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

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

  parent reply	other threads:[~2020-07-02  1:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 11:52 [ruby-core:98997] [Ruby master Feature#17000] 2.7.2 turns off deprecation warnings by deafult mame
2020-06-30 16:29 ` [ruby-core:98998] " marcandre-ruby-core
2020-07-01 12:34 ` [ruby-core:99003] " nagachika00
2020-07-01 14:47 ` [ruby-core:99004] " mame
2020-07-01 15:51 ` [ruby-core:99007] " merch-redmine
2020-07-01 17:36 ` [ruby-core:99016] " jean.boussier
2020-07-02  1:00 ` nagachika00 [this message]
2020-07-02  1:15 ` [ruby-core:99024] " merch-redmine
2020-07-04 11:34 ` [ruby-core:99052] " nagachika00
2020-07-04 17:05 ` [ruby-core:99053] " merch-redmine
2020-07-09  7:36 ` [ruby-core:99094] " mame
2020-07-10 13:58 ` [ruby-core:99110] [Ruby master Feature#17000] 2.7.2 turns off deprecation warnings by default daniel
2020-07-10 14:47 ` [ruby-core:99111] " merch-redmine
2020-07-20  3:57 ` [ruby-core:99231] " akr
2020-07-20 13:01 ` [ruby-core:99238] " nagachika00
2020-08-11  0:23 ` [ruby-core:99549] " joshua.goodall

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-86397.20200702010005.18@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).