From: "shugo (Shugo Maeda) via ruby-core" Date: 2026-07-26T00:55:43+00:00 Subject: [ruby-core:126173] [Ruby Feature#22205] Deprecate ruby2_keywords Issue #22205 has been updated by shugo (Shugo Maeda). Eregon (Benoit Daloze) wrote in #note-13: > My only question would be whether aligning both schedules for the methods might make sense, so it's more "consistent/simpler" for users. > > shugo (Shugo Maeda) wrote in #note-8: > > they are needed to deal with flagged hashes during the migration period? > > Could you give an example? I'm not sure to follow. Here is an example of `Hash.ruby2_keywords_hash?` in rspec-mocks: https://github.com/rspec/rspec/blob/8098cb121a440cbc1f9dc4581ac65edbd9f001c8/rspec-mocks/lib/rspec/mocks/argument_list_matcher.rb#L66-L70 `Hash.ruby2_keywords_hash` is used in ActiveJob to restore the flag lost by serialization: https://github.com/rails/rails/blob/be7436208a9eecd82e9d52c960bfe692c1c3263b/activejob/lib/active_job/arguments.rb#L174 The creator of flagged hashes and the code handling them can also be separate libraries. For example, `ActiveRecord::Migration::CommandRecorder` records arguments with ruby2_keywords-marked methods, and plugins such as scenic use `Hash.ruby2_keywords_hash` to restore the flag when they rebuild the recorded arguments for revert: https://github.com/scenic-views/scenic/blob/f2162dbddb0fb0eb5d4b04d640dcec5303a387e8/lib/scenic/command_recorder/statement_arguments.rb#L39-L58 In such cases, a plugin cannot finish the migration alone; it needs the Hash methods until the framework stops passing flagged hashes, so the migration requires coordination across libraries. Such code needs the Hash methods to keep working, as long as flagged hashes can exist. That is why their warning phases are one version later in the schedule that I proposed. That said, if we want to push the migration more aggressively, it may also be possible to align both schedules and remove the Hash methods together with the marking methods. ---------------------------------------- Feature #22205: Deprecate ruby2_keywords https://bugs.ruby-lang.org/issues/22205#change-118242 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- I believe ruby2_keywords should be removed in the future, but removing it now would cause compatibility issues. As a first step, how about adding deprecation warnings to ruby2_keywords? At least the following methods should emit a warning: * Module#ruby2_keywords * main.ruby2_keywords * Proc#ruby2_keywords The following methods are relatively harmless, so it might be better not to warn on them in the first step: * Hash.ruby2_keywords_hash? * Hash.ruby2_keywords_hash ## Background and Motivation While implementing Proc#refined, I noticed that the ruby2_keywords flag on an iseq (param.flags.ruby2_keywords) can be mutated by Proc#ruby2_keywords even when the iseq is shared among multiple Ractors, which is not Ractor-safe. I consider ruby2_keywords a negative legacy, and I would rather deprecate it than fix such behavior. ## Schedule ### For Module#ruby2_keywords, main.ruby2_keywords, and Proc#ruby2_keywords * 4.1: Documentation-only deprecation * 4.2: Verbose-mode deprecation warning * 4.3: Non-verbose-mode deprecation warning * 4.4: Removal ### For Hash.ruby2_keywords_hash?, Hash.ruby2_keywords_hash * 4.1: Documentation-only deprecation * 4.2: No warnings, still working as migration tools * 4.3: Verbose-mode deprecation warning * 4.4: Non-verbose-mode deprecation warning. Hash.ruby2_keywords_hash? always returns false, and Hash.ruby2_keywords_hash returns a plain duplicate of the given hash * 4.5: Removal -- 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/