Issue #21375 has been updated by Eregon (Benoit Daloze). This change also breaks concurrent-ruby: https://github.com/ruby-concurrency/concurrent-ruby/actions/runs/19414490796... https://github.com/ruby-concurrency/concurrent-ruby/issues/1093 The code relying on it seems pretty reasonable: https://github.com/ruby-concurrency/concurrent-ruby/blob/05523c01f6f2eebcb75... It expects that `initialize`/`initialize_copy` is called, no matter how the object is constructed. I suppose I can workaround by redefining `Concurrent::Set.[]` but then it might still break for other ways to create a Set, and it feels like a big hack. jeremyevans0 (Jeremy Evans) wrote in #note-2:
Relying on `Set.[]` calling `Set#initialize` was relying on undefined behavior.
No, this is very basic Ruby semantics that held so far for all objects in general and for `Set` too, and that change broke that. I think this should be a blocker for the 4.0 release. I'll add it to the next dev meeting. ---------------------------------------- Bug #21375: Set[] does not call #initialize https://bugs.ruby-lang.org/issues/21375#change-115225 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I have a subclass of Set that overrides #initialize. Following #21216, .new does call #initialize but .[] does not. ```ruby class MySet < Set def initialize(enum = nil) compare_by_identity super end end MySet.new.compare_by_identity? # => true MySet[].compare_by_identity? # => false ``` -- https://bugs.ruby-lang.org/