# Add `-Zexperimental-target`

Semi-recently, various targets, in the past, present, and possible future, have raised serious questions, like
- "Can Rust even support this target with the language's currently specified semantics?"
- "If we do add support this target, will the existing Rust ecosystem actually work with it?"
- "Is this target actually stable enough to assert it has stable platform support?"
- "How could a crate author indicate they _do_ support this target, despite it being uncommon, and how could users try out crates that _don't_ indicate they support this?"

This suggests there is a troubling coupling between "target support", and "this is definitely a stable target you can rely on having unchanged semantics", and "if rustc supports this target, all crates are expected to, too", in terms of developer experience. This seems unnecessary, as we do have a model, of sorts, for "indicate your crate supports an unusual use of the compiler/library": `#![no_std]`, which serves a kind of "secondary platform" for many targets.

For many unusual targets, a crate author may not even know if they support that target _or not_, thanks to the _relatively_ good cross-platform support in Rust. And `#![no_std]` can cause problems, too, as if you don't mark your crate with it and switch imports to `core` or `alloc`, it may link enough of `std` to prevent the intended usage, even with crates that would otherwise work fine that way. While the current situation is mostly-adequate for `#![no_std]`, if we were to generalize such a mechanism for "unusual targets", it would put unnecessary pressure on crate authors. In order to relieve pressure on possible author expectations to express explicit buy-in, and relieve pressure on target maintainers who might not actually be able to afford committing to community expectations regarding stability of current targets, we can add a compiler flag for experimental usage of support for a target on rustc nightly: `-Zexperimental-target`.

This will serve as a nightly feature gate, where _some_ targets may have their support gated on this. Many tier 3 targets already have their support de facto relegated to nightly usage with something like `-Zbuild-std`, but in the event `-Zbuild-std` gets stabilized, this flag would preserve such a gate for certain targets. It might also allow adding tier 2 support for a target but _still requiring `-Zexperimental-target`_, so that Rust programmers may benefit from a precompiled libstd.

Currently, no targets are proposed for gating on this flag, but it is suggested that maintainers who add support for a target they know is experimental in terms of Rust support (as opposed to merely _inadequately_ supported by the Rust compiler and standard library) _opt in_ to this. This should preferably be with a description of why, so that we may know when it might be made _non_-experimental, but the social messaging of opting in to such a flag is self-justifying: a maintainer may simply want more room to change things later.

To wit: this isn't about your `{x86_64,aarch64}-yet-another-unix`, nor even your `niche_risc-bare-metal`, but about your proverbial `exotic_arch-experimental_kernel`.

Likewise, no new means for indicating "this crate supports unusual targets" is _yet_ proposed, as that is a matter for T-`(lang|libs)?` consideration. The idea is to allow people to discuss such mechanisms without simultaneously proposing shutting such targets out of the entire Rust ecosystem, by eventually using `-Zexperimental-target` (or a similar flag) to experiment with crates that _don't_ opt-in, without forking each one which is impractical when testing a deep dependency tree like tokio. It might also allow crate authors to use different strategies than "demand each platform add their support to your crate".

# Mentors or Reviewers

- ???

# Process

The main points of the [Major Change Process][MCP] are as follows:

* [x] File an issue describing the proposal.
* [ ] A compiler team member or contributor who is knowledgeable in the area can **second** by writing `@rustbot second`.
* Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a `-C flag`, then full team check-off is required.
* Compiler team members can initiate a check-off via `@rfcbot fcp merge` on either the MCP or the PR.
* [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered **approved**.

You can read [more about Major Change Proposals on forge][MCP].

[MCP]: https://forge.rust-lang.org/compiler/mcp.html

# Comments

**This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.**