-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Extend Cell to work with non-Copy types #39287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -176,6 +176,7 @@ | |
use cmp::Ordering; | ||
use fmt::{self, Debug, Display}; | ||
use marker::Unsize; | ||
use mem; | ||
use ops::{Deref, DerefMut, CoerceUnsized}; | ||
|
||
/// A mutable memory location that admits only `Copy` data. | ||
|
@@ -187,23 +188,6 @@ pub struct Cell<T> { | |
} | ||
|
||
impl<T:Copy> Cell<T> { | ||
/// Creates a new `Cell` containing the given value. | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// use std::cell::Cell; | ||
/// | ||
/// let c = Cell::new(5); | ||
/// ``` | ||
#[stable(feature = "rust1", since = "1.0.0")] | ||
#[inline] | ||
pub const fn new(value: T) -> Cell<T> { | ||
Cell { | ||
value: UnsafeCell::new(value), | ||
} | ||
} | ||
|
||
/// Returns a copy of the contained value. | ||
/// | ||
/// # Examples | ||
|
@@ -221,25 +205,6 @@ impl<T:Copy> Cell<T> { | |
unsafe{ *self.value.get() } | ||
} | ||
|
||
/// Sets the contained value. | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// use std::cell::Cell; | ||
/// | ||
/// let c = Cell::new(5); | ||
/// | ||
/// c.set(10); | ||
/// ``` | ||
#[inline] | ||
#[stable(feature = "rust1", since = "1.0.0")] | ||
pub fn set(&self, value: T) { | ||
unsafe { | ||
*self.value.get() = value; | ||
} | ||
} | ||
|
||
/// Returns a reference to the underlying `UnsafeCell`. | ||
/// | ||
/// # Examples | ||
|
@@ -378,6 +343,99 @@ impl<T: Copy> From<T> for Cell<T> { | |
} | ||
} | ||
|
||
#[unstable(feature = "move_cell", issue = "39264")] | ||
impl<T> Cell<T> { | ||
/// Creates a new `Cell` containing the given value. | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// use std::cell::Cell; | ||
/// | ||
/// let c = Cell::new(5); | ||
/// ``` | ||
#[stable(feature = "rust1", since = "1.0.0")] | ||
#[inline] | ||
pub const fn new(value: T) -> Cell<T> { | ||
Cell { | ||
value: UnsafeCell::new(value), | ||
} | ||
} | ||
|
||
/// Sets the contained value. | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// use std::cell::Cell; | ||
/// | ||
/// let c = Cell::new(5); | ||
/// | ||
/// c.set(10); | ||
/// ``` | ||
#[inline] | ||
#[stable(feature = "rust1", since = "1.0.0")] | ||
pub fn set(&self, val: T) { | ||
let old = self.replace(val); | ||
drop(old); | ||
Comment on lines
+386
to
+387
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @wesleywiser do we actually need There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a comment on a very old PR. :D But no, that drop is not necessary, it probably was just there for explicitness. |
||
} | ||
|
||
/// Replaces the contained value. | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// #![feature(move_cell)] | ||
/// use std::cell::Cell; | ||
/// | ||
/// let c = Cell::new(5); | ||
/// let old = c.replace(10); | ||
/// | ||
/// assert_eq!(5, old); | ||
/// ``` | ||
pub fn replace(&self, val: T) -> T { | ||
mem::replace(unsafe { &mut *self.value.get() }, val) | ||
} | ||
|
||
/// Unwraps the value. | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// #![feature(move_cell)] | ||
/// use std::cell::Cell; | ||
/// | ||
/// let c = Cell::new(5); | ||
/// let five = c.into_inner(); | ||
/// | ||
/// assert_eq!(five, 5); | ||
/// ``` | ||
pub fn into_inner(self) -> T { | ||
unsafe { self.value.into_inner() } | ||
} | ||
} | ||
|
||
#[unstable(feature = "move_cell", issue = "39264")] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same here -- please move the |
||
impl<T: Default> Cell<T> { | ||
/// Takes the value of the cell, leaving `Default::default()` in its place. | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// #![feature(move_cell)] | ||
/// use std::cell::Cell; | ||
/// | ||
/// let c = Cell::new(5); | ||
/// let five = c.take(); | ||
/// | ||
/// assert_eq!(five, 5); | ||
/// assert_eq!(c.into_inner(), 0); | ||
/// ``` | ||
pub fn take(&self) -> T { | ||
self.replace(Default::default()) | ||
} | ||
} | ||
|
||
#[unstable(feature = "coerce_unsized", issue = "27732")] | ||
impl<T: CoerceUnsized<U>, U> CoerceUnsized<Cell<U>> for Cell<T> {} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think doing stable inside unstable makes the item stable again. At least that was the problem of bug #38860
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm not sure what the right thing to do here is. There needs to be some way to construct a non-
Copy
Cell
but perhaps it would be better to add a new function?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would advise moving the
unstable
attribute downward and applying it to each of the new methods. That generally makes it easier to track stabilization later, anyway.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do that. Do you think I should create a new function instead of moving
new()
here or is this ok?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
new
should be modified, given that we're changingset
as well. But cc @rust-lang/libs (since this makes the change roughly insta-stable).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I considered this as an implication of accepting the RFC, so immediately generalizing the behavior of
new
andset
seems ok to me.