From: shevegen@... Date: 2019-11-12T09:21:20+00:00 Subject: [ruby-core:95811] [Ruby master Feature#16345] Don't emit deprecation warnings by default. Issue #16345 has been updated by shevegen (Robert A. Heiler). I have no huge, strong preference either way because I feel you can find use cases and advantages with either way. This taps into other suggestions about ruby users being able to control the verbosity of ruby warnings in general, e. g. to adjust them to their personal use cases. I myself run with -w all the time (I just got so used to it) but I understand other ruby users not running ruby code with -w, or wanting more fine tuned adjustment. -W:deprecated or something like that seems fine; perhaps also an additional toggle-state via environment variables, like RUBY_VERBOSITY or some such (environment variables are not great, though, because it also requires of ruby users to know about them, and the more there are, the harder this becomes). I think the main issue is that there are people who like the warning, including being warned about it by default. Martin gave a good explanation and I also agree with what he wrote. So I think this is simply a case of different valid use cases that are somewhat orthogonal to each other - one "side" can reason in favour, the other against it. :) The best may be to decide on a default that covers what seems important, and to then allow ruby users to set to what they want specifically. By the way, on a side note - I think for ruby 3.0 it may be best to not change the default in this regard, and to change it past ruby 3.0. While warnings are not necessarily restricted to matz' goal of having the transition to ruby 3.0 very simple, it may still annoy some ruby users when they change to ruby 3.0 and suddenly have more verbose warning-chatter. (For me it would not matter, I can change my code either way.) > Ideally, deprecation warnings should come with additional information, i.e. version where > the feature will be removed, and/or issue on this tracker where the details are. Agreed. For me this information would be useful since I can prepare for change that way. When frozen string: true/false was enabled and added to ruby initially, I did not have a lot of code that would work with frozen strings. Today almost all of my ruby code works with frozen strings set to true, and the remaining code that does not is mostly old legacy code that I can quickly update now. So transitioning now would be simple for me - but back when it was added, it would have been quite painful. It was simpler to spread the workload over several weeks; this helped avoidd frustration too. That is why deprecation notices should ideally come way in advance. > I'm not sure making Warning.disable(:deprecated) the default is the best thing to > do, because it won't help people who use Ruby just for simple scripting (without > an explicit deploy process). It may be better for deployments to explicitly set > Warning.enable(:deprecated). I think you can find arguments in favour or in disfavour either way, depending on the use case and background of the ruby user at hand. It also depends on the warning itself. As said I use -w all the time, but some warnings are more useful than others. Some are a bit strange - first time I saw the incorrect indentation warning I wondered whether ruby was now like python. ;) It usually happens when I do a typo in my code, but I also wonder why the warning comes in general, and more importantly that we have no way to sort of "toggle" which warnings we want; we could use a model a bit similar to rubocop, although I should also add that configuring rubocop is not necessarily super-easy, so good defaults should be used for ruby whenever possible. This is mostly for a "be able to customize the warnings to your use case and style", which feels related to rubocop IMO. I think the ideal would be to have some kind of war to toggle ruby's state and behaviour in regards to warnings on a per-ruby system-wide state, without depending on code directly embedded into the .rb file (although I am also in favour of being able to toggle the state here too). IMO allowing as much flexibility as possible here. But I would suggest to change the default here after 3.0; it's not that long into the future anyway since 3.0 will come out next year. ---------------------------------------- Feature #16345: Don't emit deprecation warnings by default. https://bugs.ruby-lang.org/issues/16345#change-82637 * Author: akr (Akira Tanaka) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- We propose that Ruby doesn't emit deprecation warnings by default. Deprecation warnings are only useful when development for updating Ruby version. They are not useful when development for current Ruby. They are especially frustrated when deprecated warnings are generated in gems. Also, deprecation warnings are totally useless for production environment. So, we want to emit deprecation warnings only for useful situations. We propose a command line argument `-W:deprecated` (or `--warning=deprecated`) and 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 current our main intent is disabling deprecation warnings for keyword arguments and the warnings are generated in C level. Background: We discussed about keyword arguments at a developer meeting (2019-11-12). https://bugs.ruby-lang.org/issues/16333 We expect many deprecation warnings will be generated in Ruby 2.7. They are not useful except 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 chosen `Warning.disable(:deprecated)` instead of re-defining `Warning.warn` because avoiding string object generation. Of course, we expect extension to 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: