Implement AtomicT::update & AtomicT::try_update

[GrigorenkoPV]

ACP accepted in rust-lang/libs-team#490

@rustbot label +T-libs-api

[rustbot]

r? @Noratrieb

rustbot has assigned @Noratrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[traviscross]

During the ACP discussions today, nobody loved the name fetch_update_infallible, and there was openness to going with a better name if one could be found.

My thoughts went toward finding a verb-form antonym for the word "try". In discussion with @joshtriplett after the meeting, he insightfully observed that the verb form antonym of "try" is "do or do not" (h/t Yoda).

In all seriousness, though, the antonym of "try" is actually "do". To "do something" implies exclusion of simply "trying" to do it.

So, especially as we wish that fetch_update had been called try_fetch_update, perhaps we might consider naming this one do_fetch_update.

pub fn do_fetch_update<F>(
    &self,
    set_order: Ordering,
    fetch_order: Ordering,
    mut f: F,
) -> u64
where
    F: FnMut(u64) -> u64;

When we write that standard library naming convention guide that we talked about in the meeting today, then, we could say that we choose do_ for exactly these kind of cases where the base name is taken and we need a version that does not try_.

@rustbot labels +I-libs-api-nominated

...to consider the new naming proposal.

cc @rust-lang/libs-api

[traviscross]

In the libs-api call today, (enough) people didn't like do_fetch_update, but it did prompt a productive discussion on the name.

In terms of why fetch_update_infallible isn't the right name, Mara pointed out correctly that often exiting early represents a success case, so tying that concept to "failure" or "fallibility" doesn't make sense.

Another name proposed, by David, was fetch_update_always.

Then there was the proposal by Amanieu to deprecate fetch_update and rename both, that Josh will describe.

[joshtriplett]

We talked about this in today's @rust-lang/libs-api meeting. We didn't come to a firm conclusion yet, but we are considering the possibility of introducing new names for both functions, such as update and try_update. This would correct the issue that fetch_update should have been try_fetch_update.

[dev-ardi]

What would happen to the old occurrences of fetch_update?
Would they be marked as deprecated?
Is it worth the churn?
Should we add a lint to detect when fetch_update should have been a fetch_update_infallible (or whatever the name will be)?

[Amanieu]

Since this was still marked as waiting-on-team, we would like to clarify the team's decision: we would like update and try_update methods to be added and the old fetch_update method to be deprecated in favor of those.

[GrigorenkoPV]

Since this was still marked as waiting-on-team, we would like to clarify the team's decision: we would like update and try_update methods to be added and the old fetch_update method to be deprecated in favor of those.

What is the process on this? update & try_update get added as unstable, then, later, when they are stabilized, fetch_update is marked as deprecated? Or do we skip some steps and add something as stable immediately?

I'm hesitant to move forward before clarification, so
@rustbot label -S-waiting-on-author +S-waiting-on-team

---

On an unrelated note, what happened to the generic Atomic<T>? I thought it had been added as unstable, but I couldn't find it anywhere. Did it get removed or am I misremembering something?

[Sky9x]

Another naming option that I don't think anyone has brought up yet is fetch_modify. This function is essentially performing a "custom" atomic RMW (read-modify-write) operation.
For example, one could write foo.fetch_modify(|x| x.saturating_add(1)) for saturating atomic addition as opposed to the wrapping behavior of fetch_add.

I personally would prefer to avoid deprecating another¹ atomic method, and retaining the fetch_* prefix matches the rest of the RMW operations (eg. fetch_add, fetch_xor, etc).

Footnotes

1. The first one being CAS (compare_and_swap) ↩

[Amanieu]

What is the process on this? update & try_update get added as unstable, then, later, when they are stabilized, fetch_update is marked as deprecated? Or do we skip some steps and add something as stable immediately?

Add it as unstable first, then stabilize, then later deprecate fetch_update.

On an unrelated note, what happened to the generic Atomic<T>? I thought it had been added as unstable, but I couldn't find it anywhere. Did it get removed or am I misremembering something?

#130543

Another naming option that I don't think anyone has brought up yet is fetch_modify. This function is essentially performing a "custom" atomic RMW (read-modify-write) operation.

That's basically just a synonym for fetch_update. It doesn't give any indication of what the difference between fetch_update and fetch_modify is.

I personally would prefer to avoid deprecating another1 atomic method, and retaining the fetch_* prefix matches the rest of the RMW operations (eg. fetch_add, fetch_xor, etc).

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.

[GrigorenkoPV]

@rustbot label -S-waiting-on-team +S-waiting-on-review

[Noratrieb]

@bors r+

[bors]

📌 Commit c06ed54 has been approved by Noratrieb

It is now in the queue for this repository.