From: "Dan0042 (Daniel DeLorme) via ruby-core" Date: 2026-09-18T17:48:50+00:00 Subject: [ruby-core:126783] [Ruby Feature#22304] Add rb_warn_to_remove_at() for deprecation warnings shown by default 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/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/