You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The referenced discussion is about evaluation order. Operator precedence is something different, it's about whether A ⊕ B ⊙ C is interpreted as (A ⊕ B) ⊙ C or A ⊕ (B ⊙ C). That difference applies independently of the order of evaluation of A, B, and C.
Reacted by Tom Phinney, Jesse Schalken, John Austin, Ellen Emilia Anna Zscheile and Petr Portnov | PROgrm_JARvis
Tuples are guaranteed to be initialized in order. How about structs? Doing some marshalling. So I have things like
let vector3d = Vector3d{x: getnextvalue(); y: getnextvalue(); z: getnextvalue()};
where "getnextvalue()" is reading a value from some stream and thus has side effects.
How about the nested case?
let place = Place(pos: Vector3d{x: getnextvalue(); y: getnextvalue(); z: getnextvalue()),
rot: Quaternion(x: getnextvalue(); y: getnextvalue(); z: getnextvalue(), s: getnextvalue()));
Consensus seems to be that the structure field initializers are executed left to right, as with tuples and arrays, but no spec actually says that. It's probably worth nailing down, so some later optimization doesn't break that assumption. For example, if I have
struct Vector3 {x: f32, y: f32, z: f32}
and then initialize with
let v = Vector3(z: getnextvalue(), y: getnextvalue(), x: getnextvalue());
the compiler might conceivably do the initialization in structure order rather than initializer order. Since this sort of thing would lead to subtle optimizer-related bugs, it's probably best to prohibit it.
Activity
fweimer commentedon Feb 19, 2018
The referenced discussion is about evaluation order. Operator precedence is something different, it's about whether
A ⊕ B ⊙ Cis interpreted as(A ⊕ B) ⊙ CorA ⊕ (B ⊙ C). That difference applies independently of the order of evaluation ofA,B, andC.[-]Document operator precedence[/-][+]Document expression evaluation order[/+]Havvy commentedon Feb 19, 2018
This is what opening issues at 1AM does. Title fixed. Operator precedence is already documented.
eloraiby commentedon May 30, 2020
referring rust-lang/rust#72763: Is this the intended behaviour for a
for x in 0..function(mutable state) { .. }?ehuss commentedon Jun 1, 2020
@eloraiby Yes. The range is an expression that is constructs a
Rangevalue, which captures the bounds when it is constructed.John-Nagle commentedon Nov 15, 2020
I brought this up in the help forums, related to order of structure initialization.
Tuples are guaranteed to be initialized in order. How about structs? Doing some marshalling. So I have things like
let vector3d = Vector3d{x: getnextvalue(); y: getnextvalue(); z: getnextvalue()};where "getnextvalue()" is reading a value from some stream and thus has side effects.
How about the nested case?
Consensus seems to be that the structure field initializers are executed left to right, as with tuples and arrays, but no spec actually says that. It's probably worth nailing down, so some later optimization doesn't break that assumption. For example, if I have
struct Vector3 {x: f32, y: f32, z: f32}and then initialize with
let v = Vector3(z: getnextvalue(), y: getnextvalue(), x: getnextvalue());the compiler might conceivably do the initialization in structure order rather than initializer order. Since this sort of thing would lead to subtle optimizer-related bugs, it's probably best to prohibit it.
A Reddit discussion four years ago indicated confusion over this issue. Nobody is totally sure.