Tracking Issue for `atomic_try_update`

[GrigorenkoPV]

Feature gate: #![feature(atomic_try_update)]

This is a tracking issue for an infallible version of AtomicT::fetch_update as well as a new name for the existing fallible version.

When and if this gets stabilized, the existing fetch_update should be marked as a deprecated alias for try_update.

Public API

impl AtomicT {
    // same as `fetch_update`
    pub fn try_update(
        &self,
        set_order: Ordering,
        fetch_order: Ordering,
        f: impl FnMut(T) -> Option<T>,
    ) -> Result<T, T>;

    pub fn update(
        &self,
        set_order: Ordering,
        fetch_order: Ordering,
        f: impl FnMut(T) -> T,
    ) -> T;
}

Steps / History

• ACP: Infallible version of fetch_update libs-team#490
• Design requested by t-libs-api in Implement AtomicT::update & AtomicT::try_update #133829 (comment)
• Implementation: Implement AtomicT::update & AtomicT::try_update #133829
• Final comment period (FCP)¹
• Stabilization PR: Stabilize atomic_try_updateand deprecate fetch_update starting 1.96.0 #148590

Unresolved Questions

• Implement AtomicT::update & AtomicT::try_update #133829 (comment)

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[newpavlov]

@Amanieu

The only 2 options that we are current considering are either adding update and try_update or doing nothing and leaving fetch_update as it is. The decision will have to be made when the time comes to stabilize update and try_update as to which option we want to commit to.

Any updates on this?

I would like to migrate some of my code to update from clunky fetch_updates with closure always returning Some.

[Amanieu]

@rfcbot merge

[rust-rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

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.

[BurntSushi]

I'm ticking my box, but I don't agree with this precisely:

When and if this gets stabilized, the existing fetch_update should be marked as a deprecated alias for try_update.

If we do the deprecation, then it should lag behind the stabilization of this new API by at least one release to give folks time to migrate.

[Amanieu]

We can put a future version in the #[deprecated] attribute, which will only cause the deprecation lint to trigger starting from that rust version.

[Amanieu]

To be clear this FCP is for both the stabilization of the new methods and the deprecation of the old one. Once we stabilize these we are committing to deprecating the old method, with a future deprecation date to give people time to migrate.

[BurntSushi]

Ah okay, perfect.