Types

[nrc]

No description provided.

[nrc]

Single line formatting

[T] no spaces

[T; expr], e.g., [u32; 42], [Vec<Foo>; 10 * 2 + foo()] (space after colon, no spaces around square brackets)

*const T, *mut T (no space after *, space before type)

&'a T, &T, &'a mut T, &mut T (no space after &, single spaces separating other words)

unsafe extern "C" fn<'a, 'b, 'c>(T, U, V) -> W or fn() (single spaces around keyowrds and sigils, and after commas, no trailing commas, no spaces around brackets)

! should be treated like any other type name, Name

(A, B, C, D) (spaces after commas, no spaces around parens, no trailing comma)

<Baz<T> as SomeTrait>::Foo::Bar or Foo::Bar or ::Foo::Bar (no spaces around :: or angle brackets, single spaces around as)

Foo::Bar<T, U, V> (spaces after commas, no trailing comma, no spaces around angle brackets)

T + T + T (single spaces between types, and +).

impl T + T + T (single spaces between keyword, types, and +).

Parentheses used in types should not be surrounded by whitespace, e.g., (Foo)

Macros in type position will be covered elsewhere.

Line breaks

Avoid breaking lines in types where possible. Prefer breaking at outermost scope, e.g., prefer

Foo<
    Bar,
    Baz<Type1, Type2>
>

to

Foo<Bar, Baz<
    Type1,
    Type2
>>

[T; expr] may be broken after the ;

Function types may be broken following functions

Generic types may be broken following the rules for generics

types with + may be broken after any + using visual indent (?), when breaking such a time, all +s should be line broken, e.g.,

impl Clone +
     Copy +
     Debug

[Box<Clone +
     Copy +
     Debug>; 42]

Alternative, block indent, before + (after also works here):

impl Clone
    + Copy
    + Debug

[Box<Clone
    + Copy
    + Debug>; 42]

Option, require or allow block indent break after impl:

impl
    Clone
    + Copy
    + Debug

Question, with regard to breaking generic types, I prefer visual indent since I think it is harder to mentally line up block indent with a nested type, consider:

fn foo<T: ALongType<
    With,
    Long,
    TypeArguments,
>>(
    x: T,
    y: AnotherType
) {
   ... 
}

For me, this is hard to read since the block indented generics look like additional type params of the function, rather than type params of the type. C.f.,

fn foo<T: ALongType<With,
                    Long,
                    TypeArguments>>(
    x: T,
    y: AnotherType
) {
   ... 
}

[joshtriplett]

For tuples, please note that you need a trailing comma for a one-tuple.

As in other cases, I would strongly prefer to use block-indent. The visual-indent case you posted at the end of your comment exhibits exactly the rightward-drift problem that visual indent tends to cause and block indent tends to avoid; I find it much less readable. That said, I think your block-indent example became unreadable because you didn't follow your stated rule of "break the outermost type first". It should look like this, which I'd consider quite readable. (The extra newlines may seem excessive, but remember that this will only occur with much longer identifiers than those used in this example, and that this particular case would likely get much more readable with a where.)

fn foo<
    T: ALongType<
        With,
        Long,
        TypeArguments,
    >,
>(
    x: T,
    y: AnotherType
) {
   ... 
}

Regarding formatting of + types, we should use the same convention we use for multi-line expressions, and I'd prefer to put operators at the beginnings of lines as a general rule. See #34 (comment) for my justification; I think the same justification applies here.

[nrc]

you didn't follow your stated rule of "break the outermost type first"

I think this needs a more general case of that rule - there is not a single, nested type being broken here, but we want to break outer components of the function signature, before inner components. That seems like a fine rule to have and I agree that your formatting looks fine and also should be rare.

Regarding formatting of + types, we should use the same convention we use for multi-line expressions

agreed

[nrc]

This has been in FCP for long enough, I think we're done.

[nrc]

We've changed our process: rather than requiring a full RFC, a PR to close this issue only requires making the changes discussed here to the style guide. You can see more details about the process in the readme for this repo.

If you'd like to help with this work, let me know, I'd be very happy to help you help us.