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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tgross35]

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

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

Was there any specific resolution on this? (I have no qualms, just wondering for completeness)

[m-ou-se]

Initially, not everyone was convinced this was a good idea. Some thought that making .set() not do the same as .with(|x| x.set()) can result in subtle bugs. But after some discussion, we couldn't think of common situations where that'd easily result in bugs. We discussed some valuable use cases that are enabled by the proposed behaviour of .set(). Eventually we concluded that the proposed behaviour is acceptable and sometimes very useful, on the condition that the behaviour is well documented (which it already is).

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.