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

cmd/gofmt: inconsistent spaces around bitwise & #12720

Closed
RomanSaveljev opened this issue Sep 22, 2015 · 4 comments
Closed

cmd/gofmt: inconsistent spaces around bitwise & #12720

RomanSaveljev opened this issue Sep 22, 2015 · 4 comments

Comments

@RomanSaveljev
Copy link

@RomanSaveljev RomanSaveljev commented Sep 22, 2015

Go version: go version go1.5.1 linux/amd64

What I did: used gofmt on my source code
What I expected: have spaces around bitwise & everywhere
What I saw: in one occasion there was no spaces around the operator

I have put "before" and "after" code into a gist, so from the diff you can easily see the changes applied by gofmt

@griesemer
Copy link
Contributor

@griesemer griesemer commented Sep 22, 2015

Working as intended. gofmt uses spaces around binary expressions to express binding strength. Depending on nesting level, spaces are removed.

@griesemer griesemer closed this Sep 22, 2015
@griesemer
Copy link
Contributor

@griesemer griesemer commented Sep 22, 2015

See also issue #1206, #1848, #1861, #7880, and #11497.

Youl could also find these easily by searching for "gofmt inconsistent spaces".

@RomanSaveljev
Copy link
Author

@RomanSaveljev RomanSaveljev commented Sep 23, 2015

@griesemer I did look for duplicates although, I guess, I only checked open issues (will look better next time).

All but #11497 are closed for the reasons of emphasizing the precedence in otherwise complex expressions. Do we have to highlight in this example sort.SearchInts(arr, i & maxKeys) that & is evaluated before ,?

I read the long comment for binaryExpr:

To choose the cutoff, look at the whole expression

Is (arr, i & maxKeys) a single expression? I might be lacking the deep insights into Go now, but from other languages I practice I remember that it is not. A generic compiler may decide to evaluate function parameters in any order and there is no precedence between them "per se", which might have to be highlighted. (I might have used wrong wording here and I hope my point is understandable)

I am sorry, but in my opinion this error report is different from other closed reports. I could not find the answer from binaryExpr comment either.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Sep 23, 2015

@RomanSaveljev "(arr, i & maxKeys)" is not a single expression. But the point is that "i & maxKeys" if standing "alone", including standing alone inside ()'s, gets the space around the '&', and otherwise it won't. Which is why we get

    f(arr, i&maxKeys)
    g(i & maxKeys)
    h = (i & maxKeys)
    i = x + i&maxKeys

to show some examples. That is, an expression inside a parameter list (== a list of expressions) is treated similarly to an expression inside larger expression (e.g., "a list of terms in a sum" as in a + b + c where each a, b, c is "inside").

bzzoop added a commit to cactus/gostrftime that referenced this issue Dec 16, 2015
gofmt
gofmt formats this file differently than it used to, and results in what
at first seems like an odd inconsistency. Apparently this is by design
(see [this][1] and [this][2]), and due to nesting level.

[1]: golang/go#11497
[2]: golang/go#12720
@golang golang locked and limited conversation to collaborators Sep 23, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.