What's preventing us from giving more flexibility to the shorthand?
struct Foo {
n: i32,
s: String,
}
let n = 42u16;
let s = "bar";
Foo {
n as i32,
s.into(),
}
What's preventing us from giving more flexibility to the shorthand?
struct Foo {
n: i32,
s: String,
}
let n = 42u16;
let s = "bar";
Foo {
n as i32,
s.into(),
}
This is probably better suited for internals.rust-lang.org.
Usually, nothing strictly speaking prevents us from having more magic. But more magic is not always good – on the contrary, it's usually bad.
For example, in the above example, how would the compiler supposed to guess which field is initialized with which expression? I understand you mean "n" and "s" respectively, but it's obvious you didn't consider many more implications of this. Complex expressions can refer to any number of variables, items, etc., and then it's suddenly ambiguous which expression corresponds to which field.
Thanks moved it there: Improving struct init shorthand - language design - Rust Internals
and then it's suddenly ambiguous which expression corresponds to which field
Yes, that why I asked, no ambiguity comes to my mind. I'm not proposing to use pattern matching or something there, just as
and dot as delimeters. It feels so intuitive for me, that more then a few times I forgot it's not there.
Moved it to internals: Improving struct init shorthand - language design - Rust Internals
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.