4 Jul
2024
4 Jul
'24
10:02 a.m.
Issue #20606 has been updated by Eregon (Benoit Daloze).
I'm not opposed to changing the behavior, but raising an exception when one was not previously raised presents backwards compatibility issues. We would probably have to warn in 3.4 and not raise until 3.5 (or later).
I don't think anyone uses `thread_variable_get`/`thread_variable?` with non-String non-#to_str, non-Symbol keys (and these 2 methods are very rarely used). i.e. I think it should be fine to raise an error in 3.4 for this. It's already an error when using them and there is one thread-local variable set: ```
Thread.current.thread_variable_set :a, 1 Thread.current.thread_variable_get 12 (irb):3:in `thread_variable_get': 12 is not a symbol (TypeError)
(obviously if others feel it deserves a warning, fine by me, but it seems overkill for this)
----------------------------------------
Bug #20606: Thread#thread_variable_get, Thread#thread_variable? and Thread#[] methods handle non-String/Symbol parameter values differently
https://bugs.ruby-lang.org/issues/20606#change-108957
* Author: andrykonchin (Andrew Konchin)
* Status: Open
* ruby -v: 3.2.4
* Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
The `Thread#thread_variable_get`, `Thread#thread_variable?` and `Thread#[]` methods handle the `key` parameter that is not a String or a Symbol in different way but I would expect them to be consistent and raise an exception.
When no thread-local variables were assigned to a thread the `Thread#thread_variable_get` and `Thread#thread_variable?` methods don't raise `TypeError` when argument is of incorrect type. But `Thread#[]` does raise `TypeError` exception:
```ruby
t = Thread.new {}.join
puts t.thread_variable_get(123).inspect # nil
puts t.thread_variable?(123).inspect # false
t[123] # `[]': 123 is not a symbol nor a string (TypeError)