"A key on a computer keyboard that, when pressed, inserts a special ASCII character used for formatting text, as in indenting a line or block of text."
Actually going back it means tabulation which was an early form of alignment of tables on typewriters. The tab key advanced the carriage to the next tabulation point. It was repurposed as a way of indenting code later and it has become an additional definition of that fact.
(I'm old enough to have owned a typewriter, a nice Selectric one as well ;-)
We are talking about computer semantics which exist in a discretized world, not english language semantics. By your logic, the word integer would be any number not a fraction or decimal down to negative infinity up unto positive infinity. There is no concept of infinity on a computer.
Anyways, that's besides the point, and I think you missed the meaning behind my comment.
The reason why a tab space cannot semantically mean indentation in our world, is because nobody can agree on what that indentation should be. Since you are old enough to have owned a typewriter, maybe you are old enough to remember that by legacy, a tab was equivalent to exactly 8 spaces, and much of our software that runs the internet makes that assumption. Now however, people are saying "use tab to mean indent and everyone can have their way" To quote mikko, "There is no style guide or coding conventions saying that the tab character should be the indent. This assumption is easy to make because it allows you to stick your head into the sand, ignore the surrounding world and by singing “let the users pick their own tab width” mantra."
Again, this wasn't to start a tab vs spaces war for go, and why go chose tabs. It's fine to make a choice, but it was your second statement that provoked my comment.
I used to hate tabs and want 2 spaces only, until I started working with other developers. Then suddenly tabs made sense, especially when you've got IDEs coercing every edited file to a person's indentation standard. Standardize on the tab and the pain goes away.
Semantics is contingent upon meaning. Meaning varies and changes. Meaning is defined over time. That's the case with most words. In formatting text, it's as semantic to say that tabs are for "tabulation" and "indentation" as much as spaces are for "space" and "spacing characters." Tabs have always been semantically better as indentation in computing.
While this is clearly the wrong decision, one has to applaud the Go team for building `go fmt` and thus putting and end to unproductive discussions about formatting. (Although it would have been nice if `go fmt` didn't change code semantics.)
Can gofmt really change semantics? I would assume that's a bug?
It is definitely not supposed to change semantics. If you ever see an instance of that, then it is a big fat bug and should be reported to the developers ASAP.
I doubt you'll see such a bug though. The language is designed to be easy for a computer to parse.
It not a particularly interesting discussion to have. The short of it is, if you only ever use one tool (or family of tools) to look at code (say an IDE), then tabs are not unreasonable. Once you start using multiple families of tools on multiple machines, now you have to maintain T*M tab configurations, which is awful.
The "standard" alternative (e.g. the google c++ style guide) advises 2-space indentation with 80 column lines. That specific format works well with almost every tool in existence. Tabs, not so much.
You can google "jwz tabs" to get a more in depth discussion. It's not a "big" deal, and as noted, in many ways it's better to standardize on the "wrong" decision than to constantly hash it out over formatting sugar.
I'm relatively new to Go, and like you I wholeheartedly agree with the idea of solving formatting once and being done with it (and as an aside, I agree that tabs are the wrong decision).
It was my impression that gofmt was essentially a pretty printer. Can you point to examples where it changes semantics?
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.
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.
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.
I feel it's worth pointing out the irony in "While this is clearly the wrong decision" and "thus putting and end to unproductive discussions about formatting" considering this is part of a discussion about Go's formatting.
"Sometimes people work faster with code formatted like they are used to" - Code Creator
"Well, if we all standardize on the same style we can get used to working faster with the same format giving everyone a net win" - Me
"Well we'll have to do it after... later... deadlines... shipping" - Code Creator
Why? n spaces encode a specific preference for indentation, while tabs just represent a level of indentation. How many columns these actually are is entirely up to personal preference and editor configuration. That's why tabs are always superior for indentation.
It's actually quite a bit more subtle than that. Even `go fmt` uses tabs to format indentation, but uses spaces to format alignment. This is distinct from mechanical typewriters which used variably sized tab-stops to handle tab alignment.
