It does not change semantics. If it does in some case, that's a bug and please report it.

Edit: I see, import order can affect the order that the init()s in different packages are invoked, presumably. I stand corrected.

Edit 2: But that should not matter since the language doesn't specify any dependence on that.

no, the order is unspecified, so it shouldn't be relied upon. The only order enforced is that imported packages are initialized before the package itself.

In fact, you should be glad that "go fmt" exposed the fact you were relying on something that you should not have. Better to find a bug sooner rather than later, and relying on implementation details of your particular language implementation is a bug.

It seems to me like it would be very much in line with the Go philosophy to automatically uncover this in some way other than just an impossible-to-debug pre-compile sort, like disallowing it on a language level. Perhaps that's a Hard Problem, though, so not a reasonable request.

Well, they could do what they did with map iteration: make it happen arbitrarily different each program execution.

Breaking it randomly and requiring debugging is not the same as telling you you're doing something wrong and where.

Worked for maps :)

The same exact argument applies. The code was broken to begin with, the implementation behavior did not break anything.

And, just like with map iteration ordering, it's very difficult/impossible for the compiler to say "hey don't depend on this!".

The only way that I can think of to get this concept (that import order in code and init() order in runtime are unrelated) is to have things break.

I guess I've personally never seen the value of static initializers (in other languages at least), they always seem like the source of hard-to-find bugs. So perhaps that's really where my complaint is. Is there a compelling use for them in Go over explicit initialization?

I suppose if the runtime randomizes things, at least you would never experience it consistently working in the first place, so maybe the issue wouldn't ever come up.

Right, that's the idea.

Regarding static initializers, I use them for precompiling regexps and templates, but not much more than that.

go fmt will reorder your imports, which means that if there is an import ordering dependency, it will either be exposed (or hidden) by go fmt.

I'm just going to say whoever is downvoting this is a jerk. This comment is actually correct. Whether or not it reflects the way you believe things should happen, this is an accurate description of how things do happen (I assume, based on the other comments, I don't actually know myself).

Yes and no. `gofmt` is a tool to make your code follow certain style guidelines, and the ordering of imports is part of those guidelines. You are always free to ignore the guidelines, but then don't complain about the tool which is created to enforce them.

It is also incorrect to rely on the order of import initialization at all, because it's undefined, implementation specific and may change.

So it sounds like... yes and yes. Guidelines are guidelines. If they are more than guidelines they must be enforced at the language level.

Undefined behavior is another thing. Surely, it's poor form to rely on undefined behavior. However, that doesn't mean it isn't possible for such a situation to arise. An accurate description of how that can happen doesn't deserve a downvote.

On the contrary, it's quite valuable for a newbie (like myself) to learn the facts, not just the dogma. Downvoting an accurate description of the behavior of the tool because you think the situation shouldn't arise in the first place is simply a misplaced use of a downvote.

you should never have an import order dependency, since initialization order is unspecified.

Shoulda woulda coulda:

https://bugs.launchpad.net/gocheck/+bug/1178806

I say that's great! It helped uncover an otherwise unnoticed bug.