4 ms·
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
by skj 12y ago
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.
- couchand 12y agoI 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.
- skj 12y agoRight, that's the idea. Regarding static initializers, I use them for precompiling regexps and templates, but not much more than that.