Um, what? You've linked an RFC for Rust, but the CPP Reference article for C++ So yeah, the Rust RFC documents a proposed change, and the C++ reference documents an implemented feature, but you could equally link the C++ Proposal document and the Rust library docs to make the opposite point if you wanted.
You can also rely on the fact (not promised in C++) that these are actually the IEEE floats and so they have all the resulting properties you can (entirely in safe Rust) just ask for the integers with the same bit pattern, compare integers and because of how IEEE is designed that tells you how far away in some proportional sense, the two values are.
On an actual CPU manufactured this century that's almost free because the type system evaporates during compilation -- for example f32::to_bits is literally zero CPU instructions.
Oh, my research was wrong and the line from the RFC doc...
>Currently it is not possible to answer the question ‘which floating point value comes after x’ in Rust without intimate knowledge of the IEEE 754 standard.
So nevermind on it not being present in Rust I guess I was finding old documentation
Yeah, the RFC is explaining what they proposed in 2021. In 2022 that work landed in "nightly" Rust, which means you could see it in the documentation (unless you've turned off seeing unstable features entirely) but to actually use it in software you need the nightly compiler mode and a feature flag in your source #![feature(float_next_up_down)].
By 2025 every remaining question about edge cases or real world experience was resolved and in April 2025 the finished feature was stabilized in release 1.86, so it just works in Rust since about a year.
For future reference you can follow separate links from a Rust RFC document to see whether the project took this RFC (anybody can write one, not everything gets accepted) and then also how far along the implementation work is. Can I use this in nightly? Maybe there's an outstanding question I can help answer. Or, maybe it's writing a stabilization report and this is my last chance to say "Hey, I am an expert on this and your API is a bit wrong".
Yeah a standards document with the phrase "Currently it is not possible to answer the question" threw me, I'd argue pretty strongly that's not how standards should be written, but oh well, lesson learned.
But that's not a "standards document"? Firstly, unlike for WG21 the goal of the Rust project is to implement a programming language, the output of WG21 is an ISO Document and even though in fact the final document is largely useless the process to write it is crucial, nobody reads that official $$$$ PDF from ISO but they do use the drafts which are, though they insist otherwise for legal reasons, functionally equivalent. However the output of the Rust project is the language itself, not a standards document.
Beyond that though, neither Rust RFCs nor their nearest analogue the C++ P-series proposal papers are the output product - they're proposing to change that output and so they're written in a very different style.
Barry even starts with an anecdote! This would be entirely inappropriate for a standard but he wasn't writing a standard, like this Rust RFC he was making a proposal.
C++ implements this https://en.cppreference.com/cpp/numeric/math/nextafter
Rust does not https://rust-lang.github.io/rfcs/3173-float-next-up-down.htm... but people have in various places.