Skip to content

Add style guide for default field values#149423

Open
agraven wants to merge 2 commits intorust-lang:mainfrom
agraven:style-guide-default-field-values
Open

Add style guide for default field values#149423
agraven wants to merge 2 commits intorust-lang:mainfrom
agraven:style-guide-default-field-values

Conversation

@agraven
Copy link
Copy Markdown

@agraven agraven commented Nov 28, 2025

Tracking issue: #132162

See in particular rust-lang/style-team#205.

@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Nov 28, 2025

Some changes occurred in src/doc/style-guide

cc @rust-lang/style

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-style Relevant to the style team, which will review and decide on the PR/issue. labels Nov 28, 2025
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Nov 28, 2025

r? @traviscross

rustbot has assigned @traviscross.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@traviscross traviscross added the I-style-nominated Nominated for discussion during a style team meeting. label Nov 29, 2025
Comment thread src/doc/style-guide/src/items.md Outdated
@agraven agraven force-pushed the style-guide-default-field-values branch from 0fb8104 to 221138d Compare February 22, 2026 15:59
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Feb 22, 2026

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Comment thread src/doc/style-guide/src/items.md Outdated
The example changed to break before the `=`, but the text still said "after"; fix it to say "before the =".
Comment on lines +114 to +115
does not not fit within the right margin, split the line before the =. Also apply
a block indent if this was not already done by pulling down the type.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
does not not fit within the right margin, split the line before the =. Also apply
a block indent if this was not already done by pulling down the type.
does not not fit within the right margin, split the line before the = and indent one level further before the `=`.

@traviscross
Copy link
Copy Markdown
Contributor

traviscross commented Mar 17, 2026

struct Foo {
    a: A,
    b: B
        = long_expr,
    long_name:
        LongType
            = long_expr,
}

We talked about this in the style team call today. For my part, I'd like the indentation of the expression to be more regular -- i.e., I don't want to indent the expression further in this context-dependent way.

We confront questions similar to this elsewhere in the language. E.g., for conditionals with long conditionals, we write:

if long_cond
    && long_other_cond
{
    body
}

And not:

if long_cond
    && long_other_cond
        { body }

Similarly, we write:

let Some(
    long_pattern
) = expr;

With guard patterns, we'll even be writing:

let Some(
    long_pattern if some_long_guard_expr
) = expr;

In each of these cases, we don't indent the expression or body further. This makes sense. The expression is not a subitem of the pattern (or for default field values, the type), which is what such indentation would imply. It's a sibling. Therefore I'd expect sibling-level indentation.

Wrapping before the = helps with this. It means that the only = thing that can be at this relative level of indentation is an expression. E.g.:

struct Foo {
    a: A,
    b: B
        = long_expr,
    long_name:
        LongType<
            LongItem
                = SomeType,
        >
        = long_expr,
}

In keeping with what we do for other closing delimiters, we could also imagine doing:

struct Foo {
    a: A,
    b: B
        = long_expr,
    long_name:
        LongType<
            LongItem
                = SomeType,
        > = long_expr,
}

Where we left this, in the meeting, was trying to think of whether there was anything else we could do here, other than indentation, to make this more clear. We'll pick this back up in our next meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

I-style-nominated Nominated for discussion during a style team meeting. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-style Relevant to the style team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants