# \`cfg(extern = "rand")\`

**URL:** <https://internals.rust-lang.org/t/cfg-extern-rand/24470>\
**Category:** language design\
**Created:** [July 14, 2026, 10:08pm UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470 "2026-07-14T22:08:35Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\
**Post date:** [July 14, 2026, 10:08pm UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470/1 "2026-07-14T22:08:35Z")

</div>

I don't have the time to drive this atm; I'm mostly posting as a place to reference the idea and in case anyone else wants to pick it up.

Some `cfg` expressions can get complex or repetitive of specific data. `cfg_select!` and eventually cfg aliases can help with this but sometimes your `cfg` expressions in Rust code also need to mirror `cfg` expression and feature activations from your `Cargo.toml`. What if `rustc` made available the accessible extern names for the crate being compiled as an `extern` cfg set of values? Your Rust code can now reference the end result of `cfg` expressions and feature activations from your `Cargo.toml`.

Say we had `cfg(rust_version)`, this means you could do:

```toml
[target.'cfg(rust_version("1.20"))'.dependencies]
foo = "1"

```

```rust
fn foo_wrapper() {
    #[cfg(extern = "foo")] // in place of `#[cfg(rust_version("1.20"))]`
    {
        foo::foo()
    }
    #[cfg(not(extern = "foo"))] // in place of `#[cfg(not(rust_version("1.20")))]`
    {
        // ... some kind of polyfill logic
    }
}

```

Of course, some potential alternatives would be

- A cfg alias system in `Cargo.toml` that gets mirrored over to Rust code
- A `cfg_select!` system in `Cargo.toml` to make cfg aliases easier to express

These alternatives are likely more complex to design and would be further out for us to take advantage of. They are also extending some low level features further into Cargo and there would need to be some deliberation of what kind of line should be drawn for that.

---

<div class="post-metadata">

**Author:** ![theemathas](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/theemathas/32/11817_2.png) [@theemathas](https://internals.rust-lang.org/u/theemathas)\
**Post date:** [July 15, 2026, 3:06am UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470/2 "2026-07-15T03:06:06Z")

</div>

This is functionally identical to cfg aliases, right? How is it any different?

---

<div class="post-metadata">

**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\
**Post date:** [July 15, 2026, 5:24am UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470/3 "2026-07-15T05:24:50Z")

</div>

There are any number of things you might use to control the presence of an external dependency. The logic for that can be controlled in arbitrary ways by the build system. This sidesteps duplicating that logic into your code even once (which cfg aliases would still require), and instead allows you to check whether rustc got supplied the crate as an extern.

---

<div class="post-metadata">

**Author:** ![alice](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alice/32/5044_2.png) [@alice](https://internals.rust-lang.org/u/alice)\
**Post date:** [July 15, 2026, 8:41am UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470/4 "2026-07-15T08:41:29Z")

</div>

The main disadvantage compared to cfg aliases is that you can only use this approach if you actually have a dependency that depends on this cfg combination. It doesn't seem that different from just having a way to define `--cfg` flags from the toml directly:

```toml
[target.'cfg(rust_version("1.20"))'.cfgs]
foo = "true"

```

---

<div class="post-metadata">

**Author:** ![alice](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alice/32/5044_2.png) [@alice](https://internals.rust-lang.org/u/alice)\
**Post date:** [July 15, 2026, 8:46am UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470/5 "2026-07-15T08:46:55Z")

</div>

Another thought: In Tokio we often use cfgs that honestly _could_ just be `cfg(feature = "foo)`, but they end up more complicated because the feature has a dependency on something else:

- Only legal if you pass `--cfg tokio_unstable`
- Only legal on some targets (e.g. wasm only)
- We don't have `cfg(rust_version)`, not but if we did I could imagine wanting a higher MSRV for specific feature flags as well.

We can implement this by having a

```rust
#[cfg(all(feature = "foo", not(bar)))]
compile_error!("foo requires bar");

```

And then I'd like to just use `feature = "foo"` in the rest of the crate. But I can't actually do that because when the dependencies are not satisfied, I just want to output one compiler error, so that the user clearly sees the `foo requires bar` message. Usually I have to do `cfg(all(feature = "foo", bar))` everywhere that needs the feature because otherwise it prints a bajillion errors from random other irrelevant issues.

---

<div class="post-metadata">

**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\
**Post date:** [July 15, 2026, 11:30am UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470/6 "2026-07-15T11:30:56Z")

</div>

This is getting into

> They are also extending some low level features further into Cargo and there would need to be some deliberation of what kind of line should be drawn for that.

We've previously rejected a `[cfg]` table. Cargo focuses on abstractions of rustc features, for example we have features for defining one kind of cfg and we want globals / package parameters as another kind of cfg ([Pre-RFC: Mutually-excusive, global features](https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618)).