Skip to content

Error/warning messages should consistently use let...else #148772

Closed

Description

@carols10cents

I haven't done exhaustive checking on this, but it looks like most error/warning messages use let...else, for example:

And, most importantly to me, the next print edition of TRPL is about to go out referring to the feature as let...else.

However, there are some error/warning messages that refer to the feature as let else; I think these should be changed to let...else. Some examples:

There are also a number of places that refer to the feature as let-else, but I'm not sure how many of these are really user facing. Example:

### else blocks (let-else statements)
A let statement can contain an `else` component, making it a let-else statement.
In this case, always apply the same formatting rules to the components preceding
the `else` block (i.e. the `let pattern: Type = initializer_expr` portion)
as described [for other let statements](#let-statements).
Format the entire let-else statement on a single line if all the following are
true:

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 10, 2025
  2. carols10cents commented on Nov 10, 2025

    @carols10cents
    MemberAuthor

    @rustbot label A-diagnostics

  3. added
    A-diagnosticsArea: Messages for errors, warnings, and lints
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Nov 10, 2025
  4. jieyouxu commented on Nov 10, 2025

    @jieyouxu
  5. jieyouxu commented on Nov 10, 2025

    @jieyouxu
    Member

    I think it makes sense given appropriate context. There are two forms that we should stick with:

    1. The name of the construct is "let-else" (this is what the RFC calls it and other docs like Style Guide / RBE).
    2. The "shape" of the construct is let...else.
  6. removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 10, 2025
  7. added
    C-cleanupCategory: PRs that clean code up or issues documenting cleanup.
    D-inconsistentDiagnostics: Inconsistency in formatting, grammar or style between diagnostic messages.
    on Nov 10, 2025
  8. reddevilmidzy commented on Nov 21, 2025

    @reddevilmidzy
    Member

    I'd like to work on this issue @rustbot claim

  9. added a commit that references this issue on Nov 24, 2025
    e45ae78
  10. added a commit that references this issue on Nov 24, 2025
    738e872
  11. added a commit that references this issue on Nov 24, 2025
    ae46eb0
  12. added a commit that references this issue on Nov 25, 2025
    1bcf976
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsC-cleanupCategory: PRs that clean code up or issues documenting cleanup.D-inconsistentDiagnostics: Inconsistency in formatting, grammar or style between diagnostic messages.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions