no_std unstable - why?

[peter-lyons-kehl]

Why, or in which contexts/use cases/situations would #[no_std] equal/imply/be simnilar to unstable? But, if #61 > "Things to remove" means that this (treating of #[no_std] as unstable) is (likely) going to be removed, then please ignore this.

Otherwise: All that #[no_std] does is removal of std::. Code can still use its core:: subset (which aliases/re-exports its std:: counterpart, or rather vice-versa). And with extern crate alloc; they can use heap, too (but I believe that hardly matters here).
Either way, #[no_std] is only a subset of what is in std::, so I can't see why it would be unstable.

Thank you for cargo-semver-checks, of course.

[obi1kenobi]

I didn't write the comment you're referring to, but to my eyes it seems to be referring to something different than what you seem to have gotten out of it. I think it's referring to the removal of the heuristic about which features to test with by default: https://github.com/obi1kenobi/cargo-semver-checks#what-features-does-cargo-semver-checks-enable-in-the-tested-crates

This is case of "cargo-semver-checks can afford more guesses about what the user wants, because it doesn't have to be stable forever like cargo" which is why the stabilized cargo form of cargo-semver-checks would remove that heuristic. Otherwise there's nothing unstable or special with no_std or any of those feature names. They simply happen to be the set of features that the community at the moment happens to be using to indicate functionality that probably should not be semver-checked by default.