A new proposal has been announced: inherit stable annotations in enum variants and field items #370. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.
@T-compiler: Proposal #370 has been seconded, and will be approved in 10 days if no objections are raised.
it is quite unusual to have a stable struct/enum with public fields that are unstable
It used to be very common to have a public enum with an unstable variant, but thankfully
#[non_exhaustive] has removed essentially all of those.
As an example of a case where I could see wanting unstable-in-stable, I've pondered adding Unordered to
sync::atomic::Ordering, which would probably want to be unstable for a while.
So I like this for reduced annotation burden, but it would be nice to have a "reviewer checklist of things to look for in PRs adding something that's supposed to be unstable" somewhere.
/me has long wanted a bot that tells me "hey you're adding X Y Z to stable surface area"
might be painful to get it to work with bootstrap though
@nikomatsakis one note -- we recently had a conversation about mcps and how contentious ones would be better approved via FCP rather than the "Seconding" process. I think there has certainly been enough back and forth here for that to be merited here.
(Though I am personally fine with this)
This proposal has been accepted: #370.