Skip to content

Comments

block-expr: add new rule expr.block.result-value#2174

Merged
traviscross merged 3 commits intorust-lang:masterfrom
DanielEScherzer:patch-2
Feb 17, 2026
Merged

block-expr: add new rule expr.block.result-value#2174
traviscross merged 3 commits intorust-lang:masterfrom
DanielEScherzer:patch-2

Conversation

@DanielEScherzer
Copy link
Contributor

Document that the value of a block expression is based on the final operand (if present), just like the type.

@rustbot rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label Feb 15, 2026
Document that the value of a block expression is based on the final operand (if
present), just like the type.
@DanielEScherzer DanielEScherzer changed the title block-expr: add new rule expr.block.value block-expr: add new rule expr.block.result-value Feb 15, 2026
@DanielEScherzer
Copy link
Contributor Author

Discovered while working on a conference talk about rust, I couldn't find any rule saying that a block expression had a value equal to the final operand, so I added such a rule
Not quite sure how to phrase the part about diverging blocks - on the playground the following compiles with just some warnings about unreachable code:

fn main () {
    let result: String = { panic!("test") };
    let result: bool = { panic!("test") };
    let result: Vec<String> = { panic!("test") };
}

also, rule name could be improved, I originally was going to use expr.block.value but that is an existing rule

Blocks are always value expressions and evaluate the last operand in value expression context.

@rustbot label A-expressions

@rustbot rustbot added the A-expressions Area: Expressions label Feb 15, 2026
@DanielEScherzer
Copy link
Contributor Author

From the review policy

If this would make a new guarantee about the language, this needs to go through the lang team to be accepted (unless the lang team has clearly accepted this guarantee elsewhere). Ask @traviscross if at all unsure about any of these.

Not sure if this is a new guarantee or just documenting a long-standing reality, @traviscross does this need to go through the lang team?

When there is no final operand to a block (i.e. nothing or nothing
after the final semicolon) and the block diverges, we need to say that
there is no value as the type is uninhabited.  Let's say that.
@traviscross
Copy link
Contributor

We talked about this on the lang-docs call today. Revised as we discussed on the call. With that, look good to me. Thanks @DanielEScherzer for the PR.

@traviscross traviscross added this pull request to the merge queue Feb 17, 2026
@traviscross traviscross removed this pull request from the merge queue due to a manual request Feb 17, 2026
An earlier commit added a single rule, `r[expr.block.result-value]`,
that documented the value of a block expression in one compound
sentence.  While correct, that sentence carried a lot of weight -- the
three cases it described (final operand present, final operand absent,
and diverging) are different enough that each deserves its own rule
and example.

This commit replaces `r[expr.block.result-value]` and
`r[expr.block.type]` with three rules that each describe the type and
value together for one case:

- `r[expr.block.value-trailing-expr]`: when the block has a final
  operand, it has that operand's type and value.

- `r[expr.block.value-no-trailing-expr]`: when the block has no final
  operand and doesn't diverge, it has unit type and unit value.

- `r[expr.block.value-diverges-no-trailing-expr]`: when the block has
  no final operand and diverges, it has the never type and has no
  final value (because its type is uninhabited).

The existing example demonstrated type and value together in one
block.  We replace it with focused examples for each rule, each
demonstrating the specific case that rule describes.  A note after the
third rule highlights the distinction between omitting the final
operand and having an explicit unit final operand -- the diverging
case makes this difference visible, since `{ loop {}; }` has never
type while `{ loop {}; () }` has unit type.
@traviscross traviscross added this pull request to the merge queue Feb 17, 2026
Merged via the queue into rust-lang:master with commit 4b72668 Feb 17, 2026
6 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label Feb 17, 2026
@DanielEScherzer DanielEScherzer deleted the patch-2 branch February 18, 2026 01:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-expressions Area: Expressions

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants