# Integrity of parentheses?
**URL:** https://discourse.julialang.org/t/integrity-of-parentheses/17922
**Category:** General Usage
**Tags:** question
**Created:** [November 23, 2018, 6:39pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922 "2018-11-23T18:39:26Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Ralph\_Smith](https://discourse.julialang.org/u/Ralph_Smith)
#### Post date: [November 23, 2018, 6:39pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/1 "2018-11-23T18:39:26Z")
Does the Julia language guarantee evaluation order where parentheses are used to isolate subexpressions? For example, if one writes
```julia
d = a + (b - c)
```
can we be sure that the subtraction is performed first? This is important in implementing algorithms where one attempts to control roundoff.
I didn’t find a statement to this effect in the manual, but it appears to be the case in my (very limited) investigations. Note that some languages (e.g. Fortran) do have such a guarantee, but others (e.g. C, at least when I learned it) do not. Even if it’s true in practice now, without a guarantee (and tests!) some future “optimization” may break it.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [November 23, 2018, 7:01pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/2 "2018-11-23T19:01:00Z")
```julia
julia> Meta.@lower d = a + (b - c)
:($(Expr(:thunk, CodeInfo(
1 ─ %1 = b - c
│ %2 = a + %1
│ d = %2
└── return %2
))))
```
might be a useful tool to see what is happening “under the hood”.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [November 23, 2018, 7:03pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/3 "2018-11-23T19:03:04Z")
> [@Ralph\_Smith](#):
>
> Does the Julia language guarantee evaluation order where parentheses are used to isolate subexpressions?
Yes, this is guaranteed and is the main purpose of parenthesizing arithmetic expressions.
---
### Author:  [@mschauer](https://discourse.julialang.org/u/mschauer)
#### Post date: [November 23, 2018, 7:07pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/4 "2018-11-23T19:07:45Z")
Are you sure about your statement about C? I only know of undefined order in which modifying operators take effect, e.g. `(++i)*(++i)` is not defined, but I would first consult a reference on the question wether `a + (b + c)` can legally evaluated as `(a + b) + c` in C.
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [November 23, 2018, 7:16pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/5 "2018-11-23T19:16:00Z")
It’s not valid to do (a + b) + c. It’s the order that’s undefined, not the operation preformed
---
### Author:  [@Ralph\_Smith](https://discourse.julialang.org/u/Ralph_Smith)
#### Post date: [November 23, 2018, 7:17pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/6 "2018-11-23T19:17:08Z")
Harbison and Steele explicitly say that a C compiler may reorder evaluation of such expressions, and the references I could find online do not disagree.
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [November 23, 2018, 7:18pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/7 "2018-11-23T19:18:06Z")
C compiler has flags to allow that, but doing such transformation changes the operation preformed so it’s not allowed by the standard.
---
### Author:  [@Ralph\_Smith](https://discourse.julialang.org/u/Ralph_Smith)
#### Post date: [November 23, 2018, 7:19pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/8 "2018-11-23T19:19:11Z")
> [@StefanKarpinski](#):
>
> Yes, this is guaranteed
Thanks Stefan, I hoped that would be the case.
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [November 23, 2018, 7:19pm UTC](https://discourse.julialang.org/t/integrity-of-parentheses/17922/9 "2018-11-23T19:19:35Z")
And note that they are removing/have removed this undefinedness in c and c++ standard. On my phone so I can’t find the proposal about it.