Raising the bar for introducing new syntax


The RFC that included the argument position change argues for it in this subsection: https://github.com/rust-lang/rfcs/blob/master/text/1951-expand-impl-trait.md#motivation-for-expanding-to-argument-position


Well; to each their own :wink:


Structs by definition don’t have a set order. In fact, I would argue their canonical order should be alphabetical, not in the order of declaration.

I even proposed unnamed structs along this line of thinking with an implementation-defined layout.


This is why I don’t like calling functions with more than one argument of the same type. Multiple arguments of the same type add potential mistakes. I’d rather newtype everything.


In terms of the low-level / in-memory layout, Rust structs are already unspecified / implementation-defined. The Rust compiler is allowed to reorder the fields of your struct in memory in order to make them more compact or to optimize performance. If you need a strictly-defined layout for your structs, you have to annotate them #[repr(C)]. If you annotate your struct, because you care about the layout, then you clearly need to have full control over it, so alphabetical ordering would be useless. You would use order of declaration to specify your desired memory layout, so it matters.

In terms of source code, Rust already does not force any order onto you. You can specify the fields of your struct in any order you want when constructing them.

struct MyStuff {
    b: i32,
    a: f32,

impl MyStuff {
    fn new() -> MyStuff {
        MyStuff { a: 0.0, b: 0 }

^ this is already valid Rust code


Yes, I actually proposed structural structs so you don’t have to define them. That way they are easy to pass between crates (since you don’t have to import definitions from another crate)