I feel that if X, X.Y, and X.Y.Z are const within the function, the compiler should figure that out.
It would be difficult for a compiler to reliably tell whenever a method behaves like a constant without adding to the compilation time - and that simply isn't an option for JIT runtimes nor Go. And given it's a pretty basic optimisation for humans to pick up, I reckon it's also pretty low down on the list of "must have" features for compiler optimisations.
X.Y.Z.get("Q")
X.Y.Z.get("R")
In any case, that's not what the article was discussing and not what the majority of the comments on HN were discussing either.
I was just trying to make a quick, generic point. If it helps, imagine 4 chained method calls instead.
I haven't checked but if it was just a struct navigation (X.Y.Z.A.C, no method calls) Go probably does just optimize it to the correct offset. But bear in mind that will be an expensive pattern for CPython or Perl, for instance.
No, it's not. A mature compiler backend can successfully do this in most cases (as in, most values in most programs are proved constant). SSA form coupled with SROA, SCCP, aggressive inlining, and memory analyses are really powerful. You just need a mature, optimizing backend.
> Again, nothing specific to Go here; you'd likely be surprised what the compiler can't assume in almost any imperative language.
Mature compilers are pretty good. They can usually figure out things you expect them to. People talk a lot about aliasing and what that means for const and the like, and that's usually where the gotchas lie, but Go, like most type-safe languages, is (presumably) much friendlier to the compiler than C is in this area.
With all due respect, would you please give me a bit more principle-of-charity here? You too often pop up after a post of mine to "correct" your own too-narrow reading of it in the first place. HN is not always discussing programming things strictly in terms of Rust or similar languages; that's still just one region of a rich space.
Whether or not you think Python or Perl is a disaster of a language or not, the fact remains I have, in real life, performed non-trivial speedups of real code experiencing real problems simply by trimming those lookups, and the fact that it wouldn't have been a problem in C++ or Rust or whatever isn't particularly relevant at that point. And the fact also remains that even when the compiler is not bothered, it's still bad software engineering to create such redundant code anyhow, since it's hard to see what the code is really doing under all the cruft. (I was just complaining about how Erlang code tends to create that problem rather a lot on reddit, actually.... another language where the compiler won't save you....) And thus, it is still a perfectly valid point on a diverse site like HN to point these things out.
> you'd likely be surprised what the compiler can't
> assume in almost any imperative language
(And I say this as a Python developer who has actually needed to hoist a lookup out of a loop before.)