@Centril I think you are perhaps missing @skade’s point. I believe they are making the case that defining negative space and setting guard rails for discussions would make the community more focused and scalable. I think we should try to avoid discussing the specifics of async or turbofish here.
Personally, I tend to agree with those ideas. One challenge is how to specify negative space. I would recommend the following requirements:
- we must be able to easily and unambiguously evaluate whether a proposal falls into the negative space. For example, a “negative RFC” ought to target a specific feature (e.g. ok wrapping) or class of features (e.g. work integrating cargo with xargo).
- it must include things that are likely to be discussed if we don’t explicitly blacklist them; otherwise, a lot of time could be spent discussing hypothetical negative space that does have long term impact.
- it should be re-evaluated every once in a while as technology changes. I would propose every edition, for example.