Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document expression evaluation order #248

Closed
Havvy opened this issue Feb 19, 2018 · 5 comments · Fixed by #888
Closed

Document expression evaluation order #248

Havvy opened this issue Feb 19, 2018 · 5 comments · Fixed by #888
Labels
New Content Missing features or aspects of language not currently documented.

Comments

@Havvy
Copy link
Contributor

Havvy commented Feb 19, 2018

See also, https://internals.rust-lang.org/t/rust-expression-order-of-evaluation/2605/32

@Havvy Havvy added the New Content Missing features or aspects of language not currently documented. label Feb 19, 2018
@fweimer
Copy link

fweimer commented Feb 19, 2018

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.

@Havvy Havvy changed the title Document operator precedence Document expression evaluation order Feb 19, 2018
@Havvy
Copy link
Contributor Author

Havvy commented Feb 19, 2018

This is what opening issues at 1AM does. Title fixed. Operator precedence is already documented.

@eloraiby
Copy link

eloraiby commented May 30, 2020

referring rust-lang/rust#72763: Is this the intended behaviour for a for x in 0..function(mutable state) { .. } ?

@ehuss
Copy link
Contributor

ehuss commented Jun 1, 2020

@eloraiby Yes. The range is an expression that is constructs a Range value, which captures the bounds when it is constructed.

@John-Nagle
Copy link

John-Nagle commented 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?

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.

A Reddit discussion four years ago indicated confusion over this issue. Nobody is totally sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New Content Missing features or aspects of language not currently documented.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants