Issue #16289 has been updated by shevegen (Robert A. Heiler).


Makes sense to me what mame wrote, so +1; marcandre's suggestion for a deprecation-specific
notice makes sense as well and may be useful past ruby 3.0 (if ruby 4.x may have more
incompatibilites than ruby 3.0; then there could be more distinct "Deprecated" or
"Deprecation" messages).

Daniel wrote:

> I think the issue is more that in a long-lived process you'll get only a few warnings
> in a large log, and it may be easy to miss unless you specifically grep for the warnings.

While your comment is perfectly reasonable and makes sense as well, I think this taps into
the older discussion about customizing warnings issued by ruby, so that people can adjust
ruby to different use cases (a bit like you can customize rubocop). But this may be a
discussion past ruby 3.0 perhaps. IMO what mame wrote makes sense too since it may not be
too overly useful to have your full screen overflow with the same warning-message spam
that you already know is a problem. (Of course if there was some way to customize it in
a simple manner, ruby users could then adjust this to their general use case - but I
don't want to dilute mame's suggestion here. Picking the "right" default behaviour
covering the most likely or "best" use case of course makes a lot of sense to me and
I think most ruby users who run into this situation are more likely to want to read cozy
and helpful messages on the commandline, and using logs only secondary. :) )

marcandr's suggestion has the advantage that the leading word "deprecated" can be
colourized quite easily, e. g. people could "style" it to red on their computer;
KDE Konsole supports R,G,B style too, I use that a lot myself for different colours
(HTML colours such as "tomato" or "orangered", but I am going off-topic here a
little bit; it is also not available to everyone, of course). But in general I think
mame's description makes a lot of sense.

Note that while I understand jeremy's comment about annoying messages "helping" 
people change their code, not everyone thinks that spam is that helpful. See also
past discussions about reversing the output of the errors so that some people 
have it easier to find the problem instantly, on the last part of the message,
whereas other ruby users prefer the old style. In the long run I think it would
be best to have some larger proposal for people being able to customize ruby
warnings (and perhaps error output to, to some extent), but it should be simple
to use too. But again, sorry for diluting here, +1 to what mame wrote. I don't
think "nagging" should be of higher priority than the goal of making it simpler
to read and understand what is going on - that is also in the spirit of the 
did-you-mean gem, if you ask me.

----------------------------------------
Feature #16289: Reduce duplicated warnings for the change of Ruby 3 keyword arguments
https://bugs.ruby-lang.org/issues/16289#change-82480

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
## Problem

Currently, the interpreter emits 200 lines of warnings against the following program.

```ruby
def foo(**opt); end
100.times { foo({kw:1}) }
```

```
$ ./miniruby -e 'def foo(**opt); end; 100.times { foo({kw:1}) }'
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
...
```

In theory, the warnings are not harmful because they don't stop or interfere the execution.  But in practice, I'm afraid if they are annoying because they flush all console logs away.
I think that the warning is not needed if the call is already warned.


## Proposal

How about limiting the count of warnings to at most once for each pair of caller and callee?

I've created [a pull request](https://github.com/ruby/ruby/pull/2458).  It records all pairs of caller position and callee iseq when emitting a warning, and suppress the warning if the same pair of caller and callee is already warned.

What do you think?



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