Raising the bar for introducing new syntax


#101

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


#102

Well; to each their own :wink:


#103

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.


#104

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.


#105

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


#106

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)