People who use GCC to compile Rust code presumably will not use "cargo build" to build their programs, and presumably may not have "cargo" in their toolchains at all. They may have cmake or bazel instead, with manually-selected libraries. Perhaps you never envisioned that people would want to compile large rust programs without cargo being involved in the build flow?

Cargo, NPM, Pip, and other package managers present significant security weaknesses, and many users of C++ today do not work with this kind of flow because of this weakness. The code that Rust and C++ are aimed at is generally more security-critical than most javascript or python code.

Finally, it's great that those functions will finally be marked stable. They were stable as of 2019.

The problem I have with this isn't the specific functions, it's the process. Having functions that are stable, but waiting for years for someone to write a little bit of documentation about their stability is nuts.

I understand that people hate writing reports, but it seems that many maintainers are happy to churn out code for functions and then decide the project is finished before actually finishing it. Anyone else who wants the function is then in an awkward position: Do you want to step on someone's toes and write the stabilization report? Do you want to guarantee the stability of code that someone else wrote that you may not understand? You can't re-write it now - that would be wasteful and petty. So what do you do? You wait for someone else to take the risk.

In the Linux kernel, tons of documentation and reporting about your function being correct and stable are a prerequisite for submitting code, and this seems to work very well at preventing situations where you have lots of 90% finished projects. That is also true of most companies and most other commercially-relevant open-source projects.