Crystal Durham

FWIW, the ship has long since sailed on "only smart pointers deref". Stable std counterexamples: - https://doc.rust-lang.org/stable/std/mem/struct.ManuallyDrop.html - https://doc.rust-lang.org/stable/std/panic/struct.AssertUnwindSafe.html Unstable std: - https://doc.rust-lang.org/stable/std/lazy/struct.Lazy.html Big name library counterexamples: - https://docs.rs/lazy_static/1.4.0/lazy_static/macro.lazy_static.html -...

Minor note: `ManifestPath` isn't in violation of C-DEREF (but it is in violation of C-SMART-PTR)! This is because it wraps `AbsPathBuf` but derefs to `AbsPath`. It is thus still a...

Also, I'd just like to note that C-DEREF says that `Deref` should only be used for the purpose of smart pointers, but does not actually define what a smart pointer...

I've PRd #251 as a smaller rewording which should be fairly unobjectionable.

This is weaker than some of the other proposals I've made for how we could reword C-DEREF and/or C-SMART-PTR in #249, but I think this is a small, reasonable, incremental...

The change should IIUC slot in right here: https://github.com/rust-lang/cargo/blob/85b500ccad8cd0b63995fd94a03ddd4b83f7905b/src/bin/cargo/main.rs#L164-L174

This would also be very useful for testing e.g. `--all-features --features -legacy-compat`. (Though ofc you do need to worry about specifying the interaction with feature dependencies.)

> If we allowed general feature opt-out, it could likely break crates as they might check for a feature and assume its required features are available. FWIW I would expect...

> Then according to these semantics, `foo` will be disabled on upgrade not by my intuitive understanding, though explaining it is a bit difficult. `-bar` would disable `bar` and `default`,...

> explaining it - Collect feature requests by the current mechanism - For each `-` feature - Remove the feature request - Remove the feature requests which enable the removed...