[ruby-core:99519] [Ruby master Feature#13893] Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior

[ruby-core:99519] [Ruby master Feature#13893] Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior

[samuel]

Issue #13893 has been updated by ioquatix (Samuel Williams).


Also discussed here:

https://bugs.ruby-lang.org/issues/8215

----------------------------------------
Feature #13893: Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior
https://bugs.ruby-lang.org/issues/13893#change-86980

* Author: cremes (Chuck Remes)
* Status: Open
* Priority: Normal
----------------------------------------
Ruby 3 API cleanup suggestion.

The Thread and Fiber classes have a very odd API for setting/getting thread local and fiber local variables. With Ruby 3 coming soon, this is a perfect opportunity to make this API more coherent and return to the Principal of Least Surprise. The concept of Fibers and Threads should be completely separated and we should no longer assume that a Fiber is attached to any particular Thread.

I suggest this:

```
class Fiber
  # Gets a fiber-local variable.
  def [](index)
    ...
  end

  # Sets a fiber-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a fiber-local variable.
  def key?(key)
    ...
  end

  # Returns an array of fiber-local variable names as symbols.
  def keys
    ...
  end
end

class Thread
  # Gets a thread-local variable.
  def [](index)
    ...
  end

  # Sets a thread-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a thread-local variable.
  def key?(key)
    ...
  end

  # Returns an array of thread-local variable names as symbols.
  def keys
    ...
  end
end
```

Also, remove ```Thread#thread_variable?```, `Thread#thread_variable_get`, `Thread#variable_set`, and `Thread#thread_variables` since that behavior is already covered by `Thread#key?`, `Thread#keys`, `Thread#[]`, and `Thread#[]=`. The APIs for both Thread and Fiber are more coherent and less surprising with these changes.



-- 
https://bugs.ruby-lang.org/

[ruby-core:99537] [Ruby master Feature#13893] Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior

[eregontp]

Issue #13893 has been updated by Eregon (Benoit Daloze).


One consideration: `Fiber.current` is not available until `require "fiber"`.
So an API based on `Fiber.current` doesn't seem nice while `require "fiber"` is needed (will be NoMethodError + confusion if not required).

I think it would be too incompatible to change Thread.current#[]/[]= to anything else.
It would need first a deprecation (but so many usages it's going to be very annoying), then removal for some years, then adding back as thread-locals.
As such Fiber#[]/[]= don't seem nice, because they would just be redundant with Thread.current#[]/[]= or make it even more confusing.

The `.local` API seems nice and avoid those issues.

`Fiber.local` wouldn't need any check, but `Fiber.current.local` would need checks.
That's suboptimal as `Fiber.current.local` will need to lookup the current Fiber/Thread twice instead of once.
On Rubies without a GIL or with Ractors, `Thread.current` and `Fiber.current` will be on its their some kind of (native) thread-local lookup.
Also `Fiber.current.local` needs Fiber.current has the `require "fiber"` issue mentioned above.

----------------------------------------
Feature #13893: Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior
https://bugs.ruby-lang.org/issues/13893#change-86997

* Author: cremes (Chuck Remes)
* Status: Open
* Priority: Normal
----------------------------------------
Ruby 3 API cleanup suggestion.

The Thread and Fiber classes have a very odd API for setting/getting thread local and fiber local variables. With Ruby 3 coming soon, this is a perfect opportunity to make this API more coherent and return to the Principal of Least Surprise. The concept of Fibers and Threads should be completely separated and we should no longer assume that a Fiber is attached to any particular Thread.

I suggest this:

```
class Fiber
  # Gets a fiber-local variable.
  def [](index)
    ...
  end

  # Sets a fiber-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a fiber-local variable.
  def key?(key)
    ...
  end

  # Returns an array of fiber-local variable names as symbols.
  def keys
    ...
  end
end

class Thread
  # Gets a thread-local variable.
  def [](index)
    ...
  end

  # Sets a thread-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a thread-local variable.
  def key?(key)
    ...
  end

  # Returns an array of thread-local variable names as symbols.
  def keys
    ...
  end
end
```

Also, remove ```Thread#thread_variable?```, `Thread#thread_variable_get`, `Thread#variable_set`, and `Thread#thread_variables` since that behavior is already covered by `Thread#key?`, `Thread#keys`, `Thread#[]`, and `Thread#[]=`. The APIs for both Thread and Fiber are more coherent and less surprising with these changes.



-- 
https://bugs.ruby-lang.org/

[ruby-core:99538] [Ruby master Feature#13893] Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior

[eregontp]

Issue #13893 has been updated by Eregon (Benoit Daloze).


From #7 actually the checks would be needed in both cases, because one could save the value of `Thread.current.local` and pass it to another `Thread`.

So either `.local` API seems fine to me, but if it's `Fiber.current.local` then `Fiber.current` should become core.

----------------------------------------
Feature #13893: Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior
https://bugs.ruby-lang.org/issues/13893#change-86998

* Author: cremes (Chuck Remes)
* Status: Open
* Priority: Normal
----------------------------------------
Ruby 3 API cleanup suggestion.

The Thread and Fiber classes have a very odd API for setting/getting thread local and fiber local variables. With Ruby 3 coming soon, this is a perfect opportunity to make this API more coherent and return to the Principal of Least Surprise. The concept of Fibers and Threads should be completely separated and we should no longer assume that a Fiber is attached to any particular Thread.

I suggest this:

```
class Fiber
  # Gets a fiber-local variable.
  def [](index)
    ...
  end

  # Sets a fiber-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a fiber-local variable.
  def key?(key)
    ...
  end

  # Returns an array of fiber-local variable names as symbols.
  def keys
    ...
  end
end

class Thread
  # Gets a thread-local variable.
  def [](index)
    ...
  end

  # Sets a thread-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a thread-local variable.
  def key?(key)
    ...
  end

  # Returns an array of thread-local variable names as symbols.
  def keys
    ...
  end
end
```

Also, remove ```Thread#thread_variable?```, `Thread#thread_variable_get`, `Thread#variable_set`, and `Thread#thread_variables` since that behavior is already covered by `Thread#key?`, `Thread#keys`, `Thread#[]`, and `Thread#[]=`. The APIs for both Thread and Fiber are more coherent and less surprising with these changes.



-- 
https://bugs.ruby-lang.org/

[ruby-core:99585] [Ruby master Feature#13893] Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior

[samuel]

Issue #13893 has been updated by ioquatix (Samuel Williams).


Just one more potential interface:


```
class Fiber
  attr_accessor :my_fiber_local
end

class Thread
  attr_accessor :my_thread_local
end
```

To me, this actually seems like it should be the most logical way to add well defined/documented fiber and thread locals.

However, I also like the idea of `Fiber[]` and `Fiber[]=` as well as `Thread[]` and `Thread[]=`. However, given that in both cases keys/attribute names can clash, I don't see either one having a significant advantage. However, attributes could at least have warnings if clobbering existing attributes.

----------------------------------------
Feature #13893: Add Fiber#[] and Fiber#[]= and restore Thread#[] and Thread#[]= to their original behavior
https://bugs.ruby-lang.org/issues/13893#change-87056

* Author: cremes (Chuck Remes)
* Status: Open
* Priority: Normal
----------------------------------------
Ruby 3 API cleanup suggestion.

The Thread and Fiber classes have a very odd API for setting/getting thread local and fiber local variables. With Ruby 3 coming soon, this is a perfect opportunity to make this API more coherent and return to the Principal of Least Surprise. The concept of Fibers and Threads should be completely separated and we should no longer assume that a Fiber is attached to any particular Thread.

I suggest this:

```
class Fiber
  # Gets a fiber-local variable.
  def [](index)
    ...
  end

  # Sets a fiber-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a fiber-local variable.
  def key?(key)
    ...
  end

  # Returns an array of fiber-local variable names as symbols.
  def keys
    ...
  end
end

class Thread
  # Gets a thread-local variable.
  def [](index)
    ...
  end

  # Sets a thread-local variable.
  def []=(index, value)
    ...
  end

  # Returns true if the given +key+ exists as a thread-local variable.
  def key?(key)
    ...
  end

  # Returns an array of thread-local variable names as symbols.
  def keys
    ...
  end
end
```

Also, remove ```Thread#thread_variable?```, `Thread#thread_variable_get`, `Thread#variable_set`, and `Thread#thread_variables` since that behavior is already covered by `Thread#key?`, `Thread#keys`, `Thread#[]`, and `Thread#[]=`. The APIs for both Thread and Fiber are more coherent and less surprising with these changes.



-- 
https://bugs.ruby-lang.org/