It would be the exact same w.r.t. version resolution as a real dependency. That is, within this semver range you get at least that version, but you can still have a duplicate of a separate semver-major version.
This will not and by design cannot select a more recent version than what you'd get normally. It also does not and cannot impact normal maximal-version dependency resolution.
Well, I suppose you could add a constraint which isn't a default caret constraint, but crates-io has been super close to disallowing those for a couple years now, and you shouldn't be using them.
crates-io has forbidden uploading a package with a *
dependency since before I started using Rust. I've run into a minimal-versions selecting a *
dependency once, and that was trivially fixable by upgrading my dependency to require a nonancient version itself.
In my experience the most common minimal-versions breakage is much simpler: people specifying a dependency version earlier than the one they're developing against (either because it's been a while and this is a new checkout, or they underconstrained it initially out of some principle of e.g. only specifying the semver minor version), and then introducing a use of a newer feature.
Even if you're against yanking, it seems completely reasonable to yank packages that don't build on any 1.0+ version of Rust. These are perhaps the most justified yanks available, since the package doesn't build under any configuration.
For maximal-version dependency resolution, it doesn't matter. Adding a new (caret requirement) phantom dependency will not and cannot by design change the maximal-versions version resolution.
If you want to be thorough, you'd test that your package builds on every version resolution mode that cargo offers. There's no need to check other combinations; if someone gets one, they have a lock file witness that things were working, and if a precise upgrade fails, it's on that package for being minimal-versions incorrect.
The addition of rust-version aware version resolution will complicate things... but if you're minimal-versions correct, then a failure is entirely on the semver compliance of your upstream.
Think of [phantom-dependencies]
like a [patch]
-lite. It's a hack to work around upstream issues, and once upstream is fixed, you bump to the new upstream version and remove your hack.
Once we have a culture of minimal-versions correctness being important, then [phantom-dependencies]
will naturally fall out of usefulness. But minimal-versions correctness won't be widely seen as a think that needs to be fixed until it's available on stable, and it won't be available on stable until it's more usable than it is today, so it's a catch-22 without some hack to allow those who already think it's valuable to patch around a slower-moving upstream.