Issue #17122 has been updated by eileencodes (Eileen Uchitelle).


> I don't think we should add a category keyword if the only usage is for deprecation warnings. If we are going to do this, I think:
> 
> * All warning messages emitted by the core and the stdlib should have a category added
>   * This requires we agree on category symbols
>   * This requires new C-API warning functions added that accept a category
> * Kernel#warn should accept a category keyword and pass it to Warning.warn

As Aaron mentioned, categories already have warnings. My use-case is for deprecations, but that doesn't mean that others won't want to change behavior for other types of warnings. I could see applications raising everything but `:experimental` or only raising for `:deprecated`.

The change I'm proposing isn't introducing categories, it's adding a way to interact with existing categories. Applications can already turn off deprecations completely with `Warning[:deprecated] = false`, but there's no way to interact the other way around. What we've implemented in this PR is being able to change application behavior of warnings in specific categories. All we're doing is exposing the category kwarg and making sure that deprecation warnings get tagged "deprecated".

I like this implementation because it's lightweight and utilizes existing behavior.

> I guess we want to revisit #11588 .

For the use cases outlined here I think that structured warnings is unnecessary and more complex than what we're looking to implement. One of the things we get out of this change is the ability to have Ruby 2.7 behave like Ruby 2.8 by raising on deprecation warnings instead of silently piping them to a log file.

We run GitHub deprecation warning free. We fixed over 11k kwargs warnings in our application and want to deprecation warning free until we're running on Ruby 2.8+. The best way for us to accomplish this is being able to raise exceptions if Ruby 2.7 sees a deprecation warning. We basically want Ruby 2.8 behavior in Ruby 2.7 - anything that will break in 2.8 we want to mimic being broken in 2.7 (and continue using this pattern for future N+1 Ruby versions). I think structured warnings are more than we need to improve the interaction with warnings in Ruby.

Note: Aaron and I fixed the tests in the PR. We ended up undoing the change that turned `Warning` into a Ruby module so now this PR only implements this feature.

----------------------------------------
Feature #17122: Add category to Warning#warn
https://bugs.ruby-lang.org/issues/17122#change-87113

* Author: eileencodes (Eileen Uchitelle)
* Status: Open
* Priority: Normal
----------------------------------------
Deprecation warnings and other warnings in Ruby have a category (:deprecated, etc) but those categories aren't exposed or accessible. In the most recent Ruby 2.7 upgrade at GitHub we monkey patched `Warning#warn` to be able to turn warnings into exceptions. However, there was no way to tell which warnings were deprecations and which were other types of warnings.

I want to expose the `category` on the `Warning` module so that I'm able to monkey patch `Warning#warn` and treat deprecation warnings differently from other warnings without using a regex the strings.

Here's an example program demonstrating what I'd like to get from Ruby by implementing this feature:

```ruby
module Warning
  def self.warn(msg, category: nil)
    if category == :deprecated
      raise msg 
    else
      super
    end 
  end 
end

def ivar
  Object.new.instance_variable_get(:@ivar)
end

# Doesn't raise, but warns with verbose set
ivar

# Raises an error
Object.new.tainted?
```

The PR I worked on with @tenderlove is here: https://github.com/ruby/ruby/pull/3418

It moves the `Warning` module to be written in Ruby, updates `rb_warning_s_warn` to pass kwargs, and adds a `category` to `Warning#warn`. 



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