Issue #20864 has been updated by Eregon (Benoit Daloze). From the experience of mspec or ruby/spec which used to override `Kernel#warn` it's very confusing and messy, and I removed that. Overriding `Kernel#warn` typically also breaks `uplevel` handling and might also break the recursion check (some people user `super` in `Warning.warn`). So I think one should never override Kernel#warn, especially since we have `Warning.warn` now as the designated extension point. I wonder if we really need structured warnings. Warnings at least currently seem primarily meant for developers, and I don't really see the value for structured warnings there. So I think it would be good to have a concrete example where this would be useful and it's not trivially worked around. I would think if we want structured something it would make more sense for logging and for exceptions. Warnings are not logging. ---------------------------------------- Feature #20864: Allow `Kernel#warn` to accept `**options` and pass these to `Warning.warn`. https://bugs.ruby-lang.org/issues/20864#change-110531 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- ## Background Structured logging is a practice that organizes log data in a consistent, easily parseable format. Unlike traditional unstructured logs, which often consist of plain text entries, structured logs format information in key-value pairs or structured data formats such as JSON. This allows for better automation, searchability, and analysis of log data. In Ruby, `Kernel#warn` is extremely useful, especially because there is a mechanism for loggers to redirect warnings using the `Warning` module. However, it is difficult to generate structured logs with `Kernel#warn` as all the positional arguments are converted to a single string, and arbitrary keyword options are rejected. As a consequence, code like this is not possible: ```ruby begin ... rescue => error warn "Something went wrong!", exception: error end ``` It is very desirable to have a standard interface in Ruby for emitting structured warnings. ## Proposal I'd like to extend the current implementation to allow all options to be forwarded to `Warning.warn`. This would allow us to add more details to warnings and emit structured logs using `Warning.warn`. A simple example of the proposed interface: ```ruby module Kernel def warn(*arguments, uplevel: ..., **options) # Existing processing of arguments -> message ::Warning.warn(message, **options) end end ``` Current behaviour rejects any unknown options: ``` warn("Oops", exception: error) # => <internal:warning>:50:in `warn': unknown keyword: :exception (ArgumentError) ``` I don't have an opinion about the implementation, but I wanted to get feedback on the interface. Regarding the default behaviour, I propose no changes. -- https://bugs.ruby-lang.org/