Issue #22304 has been updated by Dan0042 (Daniel DeLorme). shugo (Shugo Maeda) wrote in #note-5:
a year cannot be converted to a version at compile time.
I don't understand why converting a year to a version at compile time would be needed. We would need to compare `year >= RUBY_RELEASE_YEAR` at compile time for the hard removal check. But for runtime deprecation warnings, displaying the target version is just a simple year-to-version mapping in a central place. When a major version bump happens, we update that single mapping, instead of editing N places across the codebase where someone hardcoded the wrong version. That seems much less error-prone. (Also, as a C habit, I have a bias toward passing integers rather than floats or strings.)
each schedule has to be reviewed and rewritten by hand at a major bump, which we should do anyway.
Sorry for the trouble, but could you explain why "we should do anyway"? I might be missing something here.
A horizon filter like `RUBY_DEPRECATION_HORIZON` ... how about proposing it in a separate ticket?
Fair enough! I can open a separate ticket for that. Though it only works if we switch to year-based targets, as version numbers make dynamic horizons tricky to calculate. ---------------------------------------- Feature #22304: Add rb_warn_to_remove_at() for deprecation warnings shown by default https://bugs.ruby-lang.org/issues/22304#change-119086 * 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/