Issue #22304 has been updated by shugo (Shugo Maeda). In addition, how about a higher-level macro that takes both versions of the schedule? ```c rb_warn_scheduled_deprecation(4.2, 4.3, fmt, suggest, ...) ``` Before 4.2 it warns only when `Warning[:deprecated]` is enabled, from 4.2 it warns by default via `rb_warn_to_remove`, and at 4.3 a RUBY_DEBUG build fails to compile. The version check is done at compile time, so the phase switches automatically on a version bump and cannot be forgotten. #22276 and #22273 can use it in 4.1 already, with no behavior change until 4.2. ---------------------------------------- Feature #22304: Add rb_warn_to_remove_at() for deprecation warnings shown by default https://bugs.ruby-lang.org/issues/22304#change-119066 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Deprecations such as #22205 and #22276 are scheduled in phases: a warning shown only when `Warning[:deprecated]` is enabled, then a warning shown by default, then the removal. For the first phase, `rb_warn_deprecated_to_remove_at(X.Y, fmt, suggest, ...)` (#17432) prints "... is deprecated and will be removed in Ruby X.Y", and a RUBY_DEBUG build fails to compile when the version reaches X.Y. For the second phase, there is no equivalent API. A warning with the `:deprecated` category is suppressed by default by definition, so the warning must be emitted with `rb_warn` without a category, and the message and the version check have to be written by hand. I propose to add `rb_warn_to_remove_at(X.Y, fmt, suggest, ...)` to internal/error.h: the same message and compile-time check, emitted with `rb_warn`. The name does not contain "deprecated" because `rb_warn_deprecated*` means a warning gated by `Warning[:deprecated]`. -- https://bugs.ruby-lang.org/