Question re `inconsistent_struct_constructor` requirement

[smoelius]

The lint's documentation states (emphasis added):

Checks for struct constructors where all fields are shorthand and the order of the field init shorthand in the constructor is inconsistent with the order in the struct definition.

What is the reason for requiring that all fields be shorthand? On the face of it, I could see value in additionally flagging fields with initializers.

[ronnodas]

Something like

struct MyStruct {
    vector: Vec<u32>,
    length: usize
}
fn main() {
    let vector = vec![1,2,3];
    MyStruct { length: vector.len(), vector};
}

won't compile if you switch the order of fields.

[smoelius1]

I think maybe I was being unclear. If the example is changed as below, Clippy flags it (playground). I'm suggesting the unmodified example be flagged as well.

struct MyStruct {
    vector: Vec<u32>,
    length: usize
}
fn main() {
    let vector = vec![1,2,3];
    let length = vector.len();
    MyStruct { length, vector};
}

[smoelius]

I would like to remove the "all fields are shorthand" requirement. How should I proceed?

1. Remove the requirement altogether.
2. Make it configurable with the current behavior as the default.
3. Make it configurable with no "all fields are shorthand" requirement as the default.

[ronnodas]

Note that the lint is currently MachineApplicable. Do you suggest that the "fixed" version of the example in my previous comment should be the following?

struct MyStruct {
    vector: Vec<u32>,
    length: usize
}
fn main() {
    let vector = vec![1,2,3];
    let length = vector.len();
    MyStruct { vector, length };
}

What if there is already a variable length in scope? Even if not, it is not clear to me that defining an extra variable is in general better than having an inconsistent ordering of the fields so I disagree with option 1 (and maybe also option 3).

[smoelius]

Note that the lint is currently MachineApplicable. Do you suggest that the "fixed" version of the example in my previous comment should be the following? ...

No, sorry, I did not mean to imply that. But I see you're point. It sounds like 2 may be the best option.