Issue #20978 has been updated by Eregon (Benoit Daloze). IIRC it was actually intentional to only allow symbols, as this makes it much more feasible to e.g. represent Fiber storage as object shapes. This was discussed on the ticket adding Fiber storage. Strings are not always interned, and interning them is a non-trivial cost. And when not interned there is a non-trivial overhead to compare them, making every access slower. At least the current code seems to intern (`rb_to_symbol()`), so using Strings is just slower but doesn't slow down every Fiber storage access. 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? ---------------------------------------- Bug #20978: Ractor[]/Thread[]/Fiber[] behavior difference https://bugs.ruby-lang.org/issues/20978#change-111328 * 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/