Tracking issue for thread local Cell methods

[m-ou-se]

Feature gate: #![feature(local_key_cell_methods)]

This is a tracking issue for thread local Cell methods: RFC 3184.

Public API

impl<T: 'static> LocalKey<Cell<T>> {
    pub fn set(&'static self, value: T);
    pub fn get(&'static self) -> T where T: Copy;
    pub fn take(&'static self) -> T where T: Default;
    pub fn replace(&'static self, value: T) -> T;
}

impl<T: 'static> LocalKey<RefCell<T>> {
    pub fn with_borrow<F, R>(&'static self, f: F) -> R where F: FnOnce(&T) -> R;
    pub fn with_borrow_mut<F, R>(&'static self, f: F) -> R where F: FnOnce(&mut T) -> R;
    pub fn set(&'static self, value: T);
    pub fn take(&'static self) -> T where T: Default;
    pub fn replace(&'static self, value: T) -> T;
}

Steps / History

• RFC: Thread local Cell methods. rfcs#3184
• Implementation: Implement RFC 3184 - thread local cell methods #92123
• Final comment period (FCP): Tracking issue for thread local Cell methods #92122 (comment)
• Stabilization PR: Stabilize thread local cell methods. #114689

Unresolved Questions

• Is the behavior of set() (to skip the default initialization) the right behavior? Yes.
• Are there any other types commonly used as thread locals for which we should do something similar?
  • Do we also want anything for UnsafeCell? Maybe LocalKey<UnsafeCell<T>>::get() to get the *mut T, just like UnsafeCell<T>::get().
  • Not a blocker for stabilizing this feature. Methods for other types can be a separate feature.

[dymayday]

Hello,
Can it be stabilized ?

[m-ou-se]

Nominated this for discussion in the next libs-api meeting.

I believe the only remaining point of discussion is the behaviour of .set():

The .set() method bypasses the lazy initialization that .with(|v| v.set()) would perform, making this pattern possible:

thread_local! {
    static ID: Cell<i32> = panic!("ID not set on this thread!");
}

fn main() {
    ID.set(123); // OK, no panic.
    println!("{}", ID.get()); // OK, no panic now that it has been set.
}

[dymayday]

Awesome ! And thank you for your answer.

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.