Allow cfg-attributes in where clauses

[recatek]

Let's make it more elegant to conditionally compile trait bounds by allowing cfg-attributes directly in where clauses.

Rendered

[teor2345]

It could help in scenarios where the right-hand side is complex, for example:
T: Iterator<Item = (U #[cfg(send_bounds)] + Send)>

But in that case I think a conditionally-compiled type alias is the way to go. (As you can see, the syntax is already a bit weird.)

This is already what many crates do, for example, type aliases like BoxError.

[recatek]

That's fair. I don't have a strong opinion on that either way. What I think this would already enable locally is:

where
    T: Iterator<Item = U>,
    #[cfg(send_bounds)]
    <T as Iterator>::Item: Send,

which IMO would be enough of an ergonomics improvement on its own without needing further complication.

[teor2345]

Yes, that seems much clearer.

If users try to add a where bound on the right, the compiler might want to suggest adding it on the left using a fully qualified path instead. But I'm not sure how easy it is to detect those scenarios.

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[scottmcm]

TBH I much prefer when we can put attributes on grouped constructs so it's clear where they end, but the parallel to existing behaviour in the generic declaration list convinced me that this is consistent enough with existing practice to just do it.

And doing it at that list level makes me feel way better than doing it in the RHS, since the RHS can just be split up if it really needs to be cfg'd separately.

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[teor2345]

Oh, I just noticed that this RFC is already in its final comment period, and my suggestions are minor wording changes. So feel free to ignore them.

[scottmcm]

So long as the approach doesn't change, updates to the RFC are fine until it's merged. (New FAQ entries in the rationale or wording fixes are certainly welcome.)

And the FCP exists to get concerns from the community, so if you have concerns, do raise them!

(You can also put things in the tracking issue later if needed. This FCP is for the RFC, but there will be another before stabilization.)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.