Repository navigation
Tracking issue for Effective Target Features #143352
Description
This is a tracking issue for the (proposed) lang experiment "Effective Target Features".
It is meant to be an experiment to evaluate whether a model for integrating target features with the propose effect system underlying const traits is feasible.
See https://hackmd.io/M5ZAoRqSTb27oLBuEpByIA for an initial proposal, and https://hackmd.io/xydafCtMQ1aqUbm6wqmEmA?view#Extending-to-target-features for more context on the syntax.
The feature gate for the issue is #![feature(effective_target_features)].
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
- Discuss in design meeting
- Approve as a lang experiment
- We accepted this experiment in the 2025-07-09 lang triage call.
- Implement in nightly
- Write and accept an RFC
- Adjust documentation (see instructions on rustc-dev-guide)
- Style updates for any new syntax (nightly-style-procedure)
- Style team decision on new formatting
- Formatting for new syntax has been added to the Style Guide
- (non-blocking) Formatting has been implemented in
rustfmt
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
Should rust-lang/rfcs#3820 be implemented before/as part of this feature?
Is the syntax proposed in the document the best option we have?
Activity
[-]Tracking Issue for Effective Target Features[/-][+]Tracking issue for Effective Target Features[/+]joshtriplett commentedon Jul 9, 2025
Happy to see experimentation in this area.
One of the open questions I'd want to see this experiment answer: how much
unsafeis required, and can we reduce that, ideally to zero?scottmcm commentedon Jul 9, 2025
I'd misinterpreted this as a multi-versioning system, which was worrisome since IIRC we're trying to start with just erasable effects (which multi-versioning of course isn't), but if this is roughly trying to make the target_feature 1.1 checks into a more "real" thing by encoding it in effects, then yes, sounds great as an experiment 👍
traviscross commentedon Jul 9, 2025
We discussed this in the lang triage call today. We're happy to accept this experiment and are all excited to see what comes of it. Many of us have been working with @veluca93 on this and plan to continue doing so as is useful to help this along.
Thanks to @veluca93 for pushing this forward.
Add an experimental unsafe(force_target_feature) attribute.
Add an experimental unsafe(force_target_feature) attribute.
Add an experimental unsafe(force_target_feature) attribute.
Add an experimental unsafe(force_target_feature) attribute.
Rollup merge of rust-lang#145573 - veluca93:unsafe-force-target-featu…
Add an experimental unsafe(force_target_feature) attribute.
Add an experimental unsafe(force_target_feature) attribute.
Add an experimental unsafe(force_target_feature) attribute.
Add an experimental unsafe(force_target_feature) attribute.
Rollup merge of rust-lang#145573 - veluca93:unsafe-force-target-featu…
Rollup merge of rust-lang#145573 - veluca93:unsafe-force-target-featu…
Unrolled build for #145573
Add an experimental unsafe(force_target_feature) attribute.
Rollup merge of #145573 - veluca93:unsafe-force-target-feature, r=dav…