Add `[` to the FOLLOW(ty) in macro future-proofing rules.

[pnkfelix]

Add [ to the FOLLOW(ty) in macro future-proofing rules (RFC #550 )

This is to address the regression rust-lang/rust#30923

[pnkfelix]

Discussed with lang-team at meeting tonight; putting into Final Comment Period (FCP) now.

(The reason for the quick FCP is because if we want to fix this, the only sensible time to do so is during the beta period, before the warning is promoted to a hard error.)

[pnkfelix]

Hear ye, hear ye. This RFC is now entering final comment period.

[retep998]

Yes please.

[nikomatsakis]

👍

[cmr]

Seems somewhat risky, were "type-level integers" to be added and made usable where constexprs are. Consider impl <N: int> SomeStruct<SomeConstantArray[N]>.

[durka]

@cmr isn't that expr [, not ty [?

[cmr]

@durka I have no idea, but I wouldn't expect so. Lots of finnicky details around those proposals.

[durka]

Well maybe I don't understand what you mean. What is SomeConstantArray? Seems to me it's an ident or an expr, but not a type.

Certainly merging this RFC restricts future syntax choices slightly. I don't really have an opinion one way or the other, except I'm against breaking all of @retep998's crates :)

[cmr]

In general a proposal could have the moral equivalent of expressions appearing in type-position. Whether they'd be treated as expr, for macros, or not I do not know.

[nikomatsakis]

@cmr good point. My expectation though is that if we were ever to embed expressions into types, we would need to have some kind of "introduction syntax" anyhow. For example, I believe I've seen it proposed that one might write `{expr}`, in which case the issue is moot.

[nikomatsakis]

Huzzah! The language design subteam has decided to accept this RFC.

[nikomatsakis]

Created tracking issue rust-lang/rust#31135 for this change specifically.