Repository navigation
Tracking Issue for SyncView #98407
Description
Feature gate: #![feature(exclusive_wrapper)]
This is a tracking issue for the SyncView wrapper struct.
This structure can be used to upgrade non-Sync objects into Sync ones, by only offering mutable access to the underlying object. This can be useful with Send-but-not-Sync futures (like BoxFutures)
Public API
// core::sync
#[derive(Default)]
struct SyncView<T: ?Sized> { ... }
unsafe impl<T: ?Sized> Sync for SyncView<T> {}
// via auto traits:
// unsafe impl<T: ?Sized + Send> Send for SyncView<T> {}
impl<T> SyncView<T> {
pub const fn new(x: T) -> Self;
pub const fn into_inner(self) -> T;
}
impl<T: ?Sized> SyncView<T> {
pub const fn as_pin(self: Pin<&Self>) -> Pin<&T>;
pub const fn as_pin_mut(self: Pin<&mut Self>) -> Pin<&mut T>;
pub const fn from_mut(x: &mut T) -> &mut Self;
pub const fn from_pin_mut(x: Pin<&mut T>) -> Pin<&mut Self>;
}
impl<T> From<T> for SyncView<T> { ... }
impl<T: ?Sized + Sync> AsRef<T> for SyncView<T> { ... }
impl<T: ?Sized> AsMut<T> for SyncView<T> { ... }
// Unconditionally implemented regardless of `T: Sync`:
impl<T: ?Sized> Debug for SyncView<T> { ... }
// + a bunch of forwarding impls (Clone, Copy, PartialEq, FnOnce,
// Future etc.) that require `Sync` when impl uses `&self`, and
// not when impl uses `&mut self`.
//
// Not yet `Iterator`, that has both `&self` and `&mut self` methods.Steps / History
- Implementation: [core] add
Exclusiveto sync #97629 - Determine other nice-to-have trait impls
- Rename: core::sync: rename
ExclusivetoSyncViewand make improvements #153038 - Final comment period (FCP)
- Stabilization PR
Unresolved Questions
- Figure out naming.
- Bikeshed certain method names (
as_pinversusas_pin_refcomes to mind). - Address the issue with the documentation example that was pointed out in Example for
std::sync::SyncViewis dubious #146245. - Decide on the fate of the
impl Debug(currently, the only nontrivial API surface that&SyncView<impl ?Sync>unconditionally implements).
Reacted by EFanZh, Alphyr, Dzenan Jupic, Xuanwo, Felipe S. S. Schneider, Joshua Chapman, Max Verevkin, ilovefurnaces, Scott Lamb, Alex Thomson and 13 more
Reacted by zohnannor
Reacted by ldanko, James C. Wise, José Luis Cruz, zohnannor and ahoyiski
Activity
clarfonthey commentedon Jun 24, 2022
This is probably a bikeshed, but perhaps the
get_pin_mutmethod could be directly implemented onPin<Exclusive<T>>, so that it can share the same name as the regularExclusive<T>version? Then maybe both could be namedget_mut, or evengetsince you'll have to use it to access non-mutable methods, just with exclusive access.This does make it asymmetric with
from_pin_mut, though, unless there were aPin::exclusivemethod.guswynn commentedon Jun 29, 2022
@clarfonthey that would conflict with https://doc.rust-lang.org/std/pin/struct.Pin.html#method.get_mut
Nemo157 commentedon Oct 20, 2022
To provide some motivation I have been using a more limited internal version of this for about 3 years in
async-compression. This is the sole bit of unsafety in that crate so I would love to be able to offload that ontostd.guswynn commentedon Oct 29, 2022
@Nemo157 I think we should try to get this in at 1.66, next week ill take a look at writing a stabilization report
zachs18 commentedon Nov 13, 2022
For the same reason that
Exclusivecan unconditionally implementSync, I believe it can also unconditionally implementcore::panic::RefUnwindSafe(which claims that a shared reference to the type is unwind-safe (i.e. can cross a panic boundary without introducing logic errors), which&Exclusiveis, because it has no API).I don't know if it would be that useful (even ignoring that there's been some disucssion about deprecating
(Ref)UnwindSafe), but I believe it could be added after stabilization if it is wanted, so it's not urgent or blocking.harudagondi commentedon Feb 17, 2023
Interestingly, in bevyengine/bevy#7718, they are adding a method called
readthat allows shared access to theirExclusiveanalogue as long as the inner type implementsSync.alice-i-cecile commentedon Feb 17, 2023
The method above is quite useful for us, but is a contradiction with the
Exclusivename of this type. As a result, we'd like to suggest renaming the type to something compatible, and adding the method linked in the PR above.This is quite a useful type, and it would be a shame to see something limited get locked in via stabilization.
(summarized from conversation in the Bevy Discord).
zachs18 commentedon Feb 18, 2023
I agree that
SyncCellor something like it could be a better name thanExclusivein the presence of afn read(&self) -> &T where T: Sync-like method, but I don't necessarily think thatExclusivebeing a contradictory name/having an exception forExclusive<T: Sync>would be too bad. There's somewhat of precedent withPin<Pointer>, which has an "exception" whenPointer::Target: Unpin, and indeed has additional API in that case, e.g.Pin::get_mut.joseph-gio commentedon Feb 19, 2023
I don't think
Pinis a the best comparison here. It makes total sense that theUnpintrait would negatePin, for obvious reasons. However, it does not make sense thatSyncwould negateExclusive, since those concepts are orthogonal. If shared access is going to be supported for this type, I don't think it makes sense to keep the current name.clarfonthey commentedon Feb 19, 2023
The main issue with using the
Cellterminology I can see is thatExclusivedoesn't useUnsafeCellinternally, whereas all other forms ofCelldo. In some sense, this actually makes it a sort of anti-cell; cells let you perform writes with immutable references, whereasExclusiveprevents you from performing reads with immutable references.What we have is some sort of static mutex, but I'm not sure if using that terminology is helpful either.
joseph-gio commentedon Feb 20, 2023
I agree that the
Cellterminology isn't great, since this type doesn't use interior mutability.I think the name should emphasize the fact that the purpose of this type is to gurantee
Sync-ness. A name along the lines ofSyncSafe<T>would be ideal IMO -- this describes the purpose of this type, and doesn't make shared access contradictory.nikita240 commentedon Aug 9, 2023
We should just name it
Icebergsince the type is used toSynctheUnsyncable.102 remaining items
tgross35 commentedon Sep 19, 2026
I thought they both work, but it seems like that one didn't resolve it either? Wonder if it's related to FCP team membership updates.
clarfonthey commentedon Sep 19, 2026
Shouldn't be…
clarfonthey commentedon Sep 19, 2026
Okay, actually, the docs are wrong, and it worked earlier in this thread? I think rfcbot is just broken.
ChrisDenton commentedon Sep 19, 2026
tgross35 commentedon Sep 19, 2026
Guess those examples just aren't improved enough 🙃
On a more serious note, I assume #146245 can be closed?
tisonkun commentedon Sep 26, 2026
Here is a stabilization PR for review - #163366
clarfonthey commentedon Sep 26, 2026
I guess we're just gonna bypass rfcbot here as obviously broken, since it's been resolved? Are we okay with not waiting the full 10 days since this is a super old FCP?
cc @Mark-Simulacrum in case you want to inspect the DB to see what's up
clarfonthey commentedon Sep 26, 2026
Okay, rechecking the date on Andrew's comment, it actually has been 10 days since the resolution. We didn't actually notify TWIR on this, but since we have an entire release cycle to undo this stabilisation, I'm going to just say it's fine and merge the other PR.
Rollup merge of rust-lang#163366 - tisonkun:codex/stabilize-sync-view…
Unrolled build for #163366 in rollup 163386