Eager optional dependencies

[Ericson2314]

I need a better name :).

Basically the idea is many crates could depend on something else, but don't need to; therefore they should depend on it automatically iff its already a included in the build plan.

The biggest example I can think of is with std. Consider features like:

• the "std" feature for https://github.com/reem/rust-void
• the "no_std" features for https://github.com/rust-lang-nursery/bitflags
• the "no_std" feature for https://github.com/rust-lang-nursery/lazy-static.rs/pull/46/files

For comparison, Haskell's Cabal has some automatic flag resolution (flag == feature, basically) https://www.haskell.org/cabal/users-guide/developing-packages.html#resolution-of-conditions-and-flags which occupies a similar niche.

[alexcrichton]

What makes this distinct from the default feature?

[Ericson2314]

Uh...I don't get how it's similar? The idea here being that these crates should not link std unless something else needs to link std.

[alexcrichton]

This seems like a pretty strong antipattern, crates magically changing their API based on other crates included elsewhere with no opt-in?

[Ericson2314]

Well, when you put it like that it does sound aweful :).

The killer app for this is making conditional impls. Because orphan impls are prohibited, they must go with the implementee or the trait, but it's kind of a nuisance to bring in extra deps just because the instances couldn't be written anywhere else. Indeed the deps are "new" precisely when impls won't be used downstream anyways.

This is precisely the case with the rust-void example I mention.

[alexcrichton]

@wycats and I talked about this today and the conclusion was:

• We don't want to implement these semantics as-is as they're a little too magical.
• This probably wants to get solved with some level of "application configuration". That is, you'd say once in the top-level Cargo.toml "please activate serde" and that would transitively be communicated to all crates.

The idea, then, is that there's a set of "community agreed upon" features (like "serde" or "std") which are commonly used amongst crates and can be opted into

[Ericson2314]

I still feel like those "'community agreed upon' features" would basically always end up being dependencies. Perhaps a good middle ground is the top-level crate states which dependencies (or even (crate with feature, triggering dep crate) pairs) it wants to use to enable features.

[cyplo]

I think I've heard @sgrif talking about something similar on the podcast ? Sorry if I'm mistaken.

[Ericson2314]

Talking to @eternaleye, I think scenarios would subsume this.

[Ericson2314]

rust-lang/rfcs#1787 is now going to pivot to this feature per the discussion there. Should I close this issue then, or wait to see where the rewritten RFC goes (in-case this should be reused the tracking issue or something)?

[epage]

Looks like this is a duplicate of #1555, so closing it in favor of that issue. If there is a nuanced difference that I missed, let me know.