In the following code, a TAB char is in s. The code doesn’t compile now:
pub fn main() !void {
// const s = " "
}
zig version: 0.14.0-dev.1951+857383689
1 Like
I think this was not done on purpose.
Sadly, it was done on purpose. In the specs it says that tabs inside of comments and multi-line string literals are illegal: grammar clarifications regarding tabs and carriage returns · Issue #38 · ziglang/zig-spec · GitHub
And this has been implemented recently in std.zig.tokenizer: simplification and spec conformance by andrewrk · Pull Request #20885 · ziglang/zig · GitHub
It’s kind of annoying in my opinion and I hope they revert it.
But I guess in your case you can fix it by using \t instead of putting the tab directly into the string literal (and to be honest tabs in string literals are kind of ugly anyways).
10 Likes
I just installed v0.14.0 and noticed the ban on tab chars in comments. The purported justification is that “it is ambiguous how [TAB] should be rendered”. But when are comments ever “rendered” by the compiler? What does that even mean?
1 Like
It said whenever rendered: not rendered by the compiler.
So…
- Whenever code is displayed
- When the comments are doc comments, converted to documentation
- When displayed by a language service provider
2 Likes
I see the point about doc comments, but for ordinary //single-line comments what is the grammatical interest in controlling how they are displayed? From the perspective of the lowly, individual, non-corporate, hobbyist programmer like myself, it’s a pain that I can no longer simply “comment out” lines of code that start with tabs. Not that I want to be a tail wagging the dog… And, off-topic but tangentially related, why are multi-line comments not supported? Seems to me coders need a convenient way to disable blocks of code during development.
I don’t mean to rant. I love coding in Zig, and appreciate the added challenge of learning a language that is under active development and therefore constantly changing. Just adding my //two cents. 
many editors have the feature of replacing tabs with spaces, zig fmt also does this.
most editors have a feature to comment selected code with a key bind
1 Like
Because zig uses a no-context parser. It is possible to parse a line of zig code without seeing any other lines, which helps with parallelization. Having mutli-line comments breaks this property.
2 Likes
I just installed Zig for the first time. I was waiting for some settling down time. My first program gave “helloWorld.zig:2:9: error: comment contains invalid byte: ‘\t’”
For me, this is overreach by a massive amount. Comments are supposed to be ignored by the compiler. Whitespace is syntactically ignored. So, what do I do?
rd /s/q C:\\ProgramFiles\\ziglang.org\\
I’m not interested in using a language that is so authoritarian. Shame. I had hopes. I don’t have a problem with there being a canonical standard. That’s what code formatters are for. Compilers should not enforce layout. That’s what formatters are for. Stopping me using tabs for layout and comments is not the business of the compiler. So, after not ever getting to the stage of actually running the “Hello World”:
rd /s/q “C:\\Program Files\\Ziglang.org\\”
P.S. I’m not saying the Zig has to do it differently. If that’s what you want then go for it. I’m just not going to participate. If it’s important to you then, imho, you’re worrying about the wrong things.
1 Like
Use spaces. I am unaware of any modern code editor that lacks an option to insert spaces for tabs.
Your frustration is understandable, it wasn’t an especially popular choice to not allow tab character in comments, but I assume most simply see this for what it is: a minor inconvenience.
If your issue is something deeply philosophical or in opposition to your convictions, then I don’t really have much advice. Personally for me, this doesn’t seem like a hill to die on. I can’t think of a single language that has ever existed that didn’t have some minor “flaw” that I wished to be different.
4 Likes
Thanks ForeverZero for taking the time to reply. Good reply and with valid points that I agree with. You’re right. It’s not a hill to die on. So I walked away. You’re right also about not a single language that has ever existed … but this isn’t about the language. It’s about the overreach of the implementation into content that is explicitly NOT part of the functional language - comment content. The lexical tokens that introduce comments, whether the language supports/allows multiline comments, whether inline comments are supported are part of the language syntax. The handling of “ordinary comments” is defined here: Documentation - The Zig Programming Language “There are three types of comments. Normal comments are ignored,” I also happen to think that it’s a waste of development time and effort to make Doc Comments and Top-Level comments part of the compiler’s job. There are plenty of other tools for doing that. And plenty of other organisations have developed their own standards and tools for these things. The good thing about standards is that there are so many to chose from. So, sorry, exerting control over how I with MY standards format comments goes too far for me. Using spaces is not a functional replacement for tabs. For example, it makes editing tables laid out with text much more tedious to edit and modify. Anyway, thanks for your sympathy and understanding. Perhaps I’ll just go back to MACRO-11 
1 Like
But having the language make that choice means the usage and experience is consistent across projects which is a major boon, similar benefits as having a standard formatting.
You are right that there are many decent options, so it only matters that the choice is usable. But since zig is pre 1.0 you are free to voice your constructive criticism to help make zig even better.
I am on your side with tabs, but andrew is not. He did relent and allow tabs in source code, which he re disallowed in comments later.
It is not that big of an issue, but it is odd for him to do something without a decent justification even if it ends up being flawed in which case he walks it back.
There are a lot more important issues to work on, this can be bikeshedded closer to 1.0.
2 Likes