Specifically bstrie's suggestion of `ExpressionWithoutBlock`.

Also some spelling fixes and example updates.

Thanks to Frank Steffahn for pointing this out in Zulip.

By request of Josh Triplett

Also mentions the diverging return type of `!` in the summary.

Co-Authored-By: Josh Triplett <[email protected]>

- Example now shows side-effects and dependence, cannot be reproduced by a single large `match`.
- Note lazy boolean operator dis-allowance more prominently
- Note `irrefutable_let_patterns` lint warning.
- Make a decision for the if-let-chains future possibility: just disallow the problematic case
- Clarify the note about `static` and `const` _items_.
- Add section about "let-else within if-let" (I guess this RFC had it coming for it)

- Clarify the diverging return type to be anything which returns never.
- More detailed desugaring example with the above point.
- Get rid of `BlockExpressionDiverging`.
- Alternative: `let` assignment from `match`.
- Alternative: `||` in pattern matching.
- Prior art: `guard!` macro.

per Josh's recommendation and general discussion

Most of this was Josh's suggestion and some is his words almost verbatim.

Co-Authored-By: Josh Triplett <[email protected]>

Thanks to lebensterben for catching this one

long sigh

- Clarify that `: TYPE` is allowed, as per Josh
- Note the expression restriction more accurately and with more detail, as per Niko
- Removed the option-chaining example, because many people keep stopping at that to comment.
- Note a macro as an (unfavorable) alternative.

Co-authored-by: J. Frimmel <[email protected]>

Hopefully this will be my last round of updates.

- Added some unresolved questions.
- Fixed some typos / english language clarification.
- Clarified that all expressions ending in `}` should be disallowed.
- Fixed some errors in examples.
- Added section on `, else`.
- Updated the `unless let` section to be "Introducer syntax" with the noted keyword being `guard`.
- Noted the `DIVERGING_EXPR` section with more detail.

Excluding the block grammar clarifications for now, because those have evolved somewhat in Zulip.

Co-authored-by: Mario Carneiro <[email protected]>

As per discussion in GitHub and Zulip, this seems like the most straightforward path until practical experimentation can be done.

Forgot this in the last commit. Invisible groupings from macros should be allowed but should be shown to humans in visible expansion tools.