Closed nrxus closed 3 years ago
What if you added reckless_then
as a "safe" version of then
which just lies about the safety? You can gate the exposure of that method on a crate feature, and that way one crate turning it on won't cause other crates in the dependency graph to experience any behavior changes.
Do you mind linking me documentation on how feature flags poison through cyclic dependencies? My google-fu is failing me.
[dependencies]
crate-b = { version = "0.1.0", features = ["foo"] }
crate-c = "1.1.0"
[dependencies]
crate-b = { version = "0.1.0", features = ["baz"] }
At this point, crate A would see both foo
and baz
features enabled. That's why features are supposed to always be additive, and to avoid being mutually exclusive whenever possible.
Ah!
That makes sense now. Hmm I am not a huge fan of reckless_then
but I will consider it as I think of alternatives. I do not think this is a very high priority issue anyway, explicit unsafe
will do for now.
faux
can now handle a lot more code with safe Rust so this is no longer needed.
Writing unsafe on every mock is a bit annoying.
What if we added a feature called
unsafe
ori-know-faux-is-unsafe-so-hush
that if turned on exposed the mocking methods as "safe" since the user has already opted-in the unsafety at the crate level.