Hello everyone! I’ve recently decided to blow some dust off of my old project I started writing in zig 0.13. Now that 0.14 is out, I’ve decided to upgrade the project to the newest version, and I’m hitting this error message when trying to compile the project in quite a lot of places, but I can’t seem to find any information on it. Is it a known regression, or should I report it to the issue tracker?
Yes it is intentional. The latest zig distribution doesn't allow TAB chars in comments?
1 Like
Oh wow. Because of rendering? This is so frustrating.
Andrew should ban letters next, so the user can’t use non-monospaced fonts to break “rendering”…
6 Likes
In terms of fixing it, this shouldn’t be frustrating. Any editor, or sed, will expeditiously replace tabs with spaces.
In terms of inherently wanting tabs in your comments, I can see in the abstract that yes, that would be frustrating. In concrete terms I don’t get why configuring your editor to insert the number of spaces you would like a tab to be would be enough to cause frustration.
The end game here seems to be that tabs aren’t legal in Zig code, but zig fmt will fix them when used as whitespace. I’m fairly sure the comment about rendering is just saying that letting the user replace comment tabs is better than auto-formatting, because the formatter doesn’t know the tabstops, so it shouldn’t guess.
That all said, banning them from multi-line string literals seems actually bad to me. A situation where makefiles can only be embedded in Zig code through fairly elaborate transformation seems distinctly sub-optimal.
It’s the difference between taking a strong stance against \t in Zig code, which is defensible although I don’t personally care about the issue, and failing to recognize that the rest of the world does not universally agree with that principle. Multi-line string literals are, among other purposes, for embedding other string formats, and the reality is that some of those formats use, or in Make’s case require, tabs.
There’s a principle involved here, which is that one can always strengthen a promise, or loosen a restriction, but going the other way is difficult. In other words, Zig could always allow tabs later in multi-line strings, but getting rid of them elsewhere becomes more painful over time.
2 Likes
In 0.10 Zig has made the decision to allow tabs as whitespace. Before that people had to get creative and write custom build steps that automatically generated copies of files with all tabs replaced.
If Zig keeps making life hard for tab users with stupid restrictions like “You use tabs, we will punish you by not allowing you to comment out code”, that will just push tab users back to using these workarounds again, which in my opinion hurts everyone.
2 Likes
Commenting out code is a terrible habit! use if (XXX) where const XXX = false;. Anyway…
I think the end game here (just from reading this issue and that) is one where zig fmt will replace tabs for you, but zig proper won’t compile them, and will tell you to use zig fmt to clean up your code. Tabs remaining valid whitespace is an unstable equilibrium and I wouldn’t expect it to last.
I’ve decided not to have an opinion about this, all I have an opinion about is “use zig fmt”. Whatever it does to my code is how it ends up, when that isn’t acceptable I turn it off for a region. That’s rare.
I cannot successfully put myself in the headspace of someone for whom tabs are so potent a source of self-identity that they would use them, and then do code transformation to get the tabbèd-upon code to compile. Just can’t. Cards on the table, I’m on team spaces, but, I’m also a go fmt enjoyer, even though it’s a dark servant of the Tab Empire, my sworn enemy or whatever.
What I do care about, and dislike, is that the multi-line literal rule means that go fmt-ed upon Go would need ruthless mangling to embed it in Zig. That’s a design flaw. Whatever the purpose of the spaces supremacy movement is supposed to be, it’s going too far there.
2 Likes
Although I hate tabs… A string should be able to contain tabs. Can it not?
If a string can contain redhaired greeneyed astronaut emoticons why no tab?
Zig fmt. How do I use that? I never format my code (using vscode), because I don’t know how!
(Most probably we are stuck with a non-optional “asymmetrical unreadable braces on same line” anyway, as the world seems to have adopted)
2 Likes
I never format my code (using vscode), because I don’t know how!
If you don’t know how to do something in vs code, you can most of the time search answer in command palette (ctrl+shift+p)
2 Likes
Not Zig-related, but here’s a silly example of (presumably) unintended behavior from tabs in string literals in .rc script files.
3 Likes
7 posts were split to a new topic: Dead Code: Comments or Conditional Compilation?
Incredible. Some basically wrong designs (utf, html) we are stuck with for a looooong time