clearly define the intended purpose of feature gates in the documentation

[thestinger]

Do experimental features need to be accepted as an RFC to be added behind a feature gate? For example, #![feature(struct_inherit)] was added after the RFC process was put in place.

At the moment, some RFCs are closed and classified as postponed rather than being rejected. It isn't clear whether this means initial experimental work can happen behind a feature gate, especially in cases where it isn't a large / invasive feature.

[nrc]

Yes. Features that were accepted by the old 'process' of meeting discussions are considered to be grandfathered in (there is no RFC for DST for example).

(For the record, the first PR for struct_inherit landed on the 26th Feb and the RFC process began around the 12th March (date of first PR). If struct_inherit were proposed now, it would need an RFC and indeed there are several proposed RFCs for development of the idea and no work has been or will be done until that's gone through the RFC process).

[lucy]

Perhaps it should be possible to have RFCs accepted for implementation behind a feature gate (if anyone is interested) despite not being in scope for 1.0?

[sanxiyn]

RFC PR 15(SIMD) is entirely behind a feature gate but rejected. I infer that even the experimental work behind a feature gate needs to go through RFC if it is "substantial", in the language of RFC 1. I don't exactly agree with that, but that seems to be the status quo.

[steveklabnik]

This story is clear now, as all new features will land behind a gate until they are deemed stable.