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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>