[#99115] [Ruby master Bug#17023] How to prevent String memory to be relocated in ruby-ffi — larskanis@...
Issue #17023 has been reported by larskanis (Lars Kanis).
22 messages
2020/07/10
[#99375] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings — merch-redmine@...
Issue #17055 has been reported by jeremyevans0 (Jeremy Evans).
29 messages
2020/07/28
[#101207] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings
— merch-redmine@...
2020/12/02
Issue #17055 has been updated by jeremyevans0 (Jeremy Evans).
[#101231] Re: [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings
— Austin Ziegler <halostatue@...>
2020/12/03
What does this mean?
[ruby-core:99363] [Ruby master Feature#16345] Don't emit deprecation warnings by default.
From:
mame@...
Date:
2020-07-27 23:36:33 UTC
List:
ruby-core #99363
Issue #16345 has been updated by mame (Yusuke Endoh). I'm not sure if this is the right way. I agree that a deprecation warning is annoying for end users. I also understand that application developers don't want them to be nervous. However, disabling the warnings by default does not solve the deprecation issue itself, but just postpone it. And the issue will be suddenly active when Ruby version is upgraded. Do people really want to see sudden break? That being said, now I'm not strongly against the policy change. * Some people actually complain the deprecation warnings for keyword change. * The issue can be mitigated if all test frameworks enable all deprecation warnings. * Sudden break is never a good thing, but may be a very strong motivation to fix applications (though it makes all users more nervous.) But, I'm still unsure if it is a good practice in total. ---------------------------------------- Feature #16345: Don't emit deprecation warnings by default. https://bugs.ruby-lang.org/issues/16345#change-86763 * 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/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
