Add expr202x macro pattern by lf- · Pull Request #84364 · rust-lang/rust (original) (raw)

Hmm, I'm in favor of the concept overall, but I'd like to have a bit of a "write-up" or something that brings together the required information. I don't quite remember, for example, what changes were required to the expr non-terminal and why.

Alright, that's entirely understandable! So it looks like the back compat thing for let chaining came from this comment discussion: #60861 (comment) and an associated fixme in the feature gate ui test introduced by that pr which passes here because this pr doesn't inflict the new behaviour on any edition yet. In other words, this one is here because of conservatism. But we can probably assume that someone out there has written a macro that depends on the exception in the current expression behaviour based on the next one's experience:

The other exception for inline const was because we got bitten by the issue that was proposed in the above discussion, but in the context of inline const. This exception got in because of #80135: it was needed to keep some macros on beta working, which expected the const keyword then some expression after, as I understand it based on my testing and reading examples.

The former exception was removed here since I was bifurcating anyway and could reserve it. The latter was because of inline const needing to have parens around it to be valid in macro invocations currently, which is odd and rather confusing (I didn't know about this trick to get it accepted by the parser until it was pointed out to me by a friend so I assumed it simply wasn't allowed. the error here is bad too). Macros taking :expr seem liable to hit an issue shaped like this whenever a syntax extension to expressions happens, as a form of inherent fragility, so it's probable some more exceptions like these might get introduced as extensions get added.

Does this need to happen now? Not strictly. It could happen later or never, at the expense of macros being a little more confusing: This PR was written while I was under the invalid impression you couldn't pass a const block to a macro as an expression, which I now know is possible with parens, but that fact was anything but discoverable. It would be good to resolve the syntax ambiguity to favour consistency in being able to put const { ...} anywhere an expression could go, including in macros, imo. I'm not super familiar with let chaining or how this applies in its case, although I'd be inclined to believe that a similar argument could be made.