Issue #20978 has been updated by zverok (Victor Shepelev).
Why would anyone want to use strings for this API, if it's going to be converted to Symbol internally anyway and so slower than using the Symbol?
TBH, I’d, too, rather expect only Symbols to work for such “system programming” (so to say) APIs. I just raised a concern about the inconsistency of similar APIs here. ---------------------------------------- Bug #20978: Ractor[]/Thread[]/Fiber[] behavior difference https://bugs.ruby-lang.org/issues/20978#change-111329 * Author: zverok (Victor Shepelev) * Status: Closed * ruby -v: ruby 3.4.0dev (2024-12-22T06:08:19Z master 3808d29e20) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `Ractor.[]` and `.[]=` support string and symbol keys (treating them by string value, and also accepting anything responding to `#to_str`): ```ruby Ractor[:value] = 10 Ractor[:value] #=> 10 Ractor['value'] #=> 10 o = Object.new def o.to_str = 'value' Ractor[o] #=> 10 Ractor[1] # in 'Ractor.[]': 1 is not a symbol nor a string (TypeError) ``` But `Fiber.[]` only accept symbols: ```ruby Fiber[:value] = 10 Fiber['value'] # in 'Fiber.[]': wrong argument type String (expected Symbol) (TypeError) ``` `Thread#[]` and `#[]=` behave like Ractor’s. (The documentation for Fiber and Thread follows the reality—while Ractor’s current docs don’t specify key type at all—but the discrepancy feels somewhat weird.) -- https://bugs.ruby-lang.org/