Some of these look like good ideas. Some look like bad ideas:<p>> Tab character in source code is a compile error. Whitespace at the end of line is a compile error.<p>Both of these seem like bad ideas, except perhaps tab characters in string literals (or anywhere else that replacing it with an arbitrary number of spaces changes the meaning of the program) should be errors. Whitespace at the end of the line, also should not be an error unless deleting them would not change the meaning of the program. (Another reason to disallow tabs would be if indentation-sensitive syntax is used (like Python), although I dislike the indentation-sensitive syntax anyways.)<p>(Also, I often have spaces at the end of a line in incomplete programs I write in C; usually this will be eliminated if that part of the program is complete, though.)<p>> Source code is UTF-8.<p>Also bad. It is an unnecessary restriction, unless you want to use a "secure character set" (which should probably be an option and not mandatory, anyways), in which case it is an insufficient restriction (ASCII only (without most controls) would be better). If you do want the "secure character set", then the alternate restrictions for tabs and trailing spaces that I mentioned above, would help.<p>However, since you can run code at compile-time, if that allows reading other files in the same directory then you can put any non-ASCII text that you need, in other files, and then load them at compile-time. (This is much cleaner than the messy ways of having to deal with mixed text directions (and other stuff) in Unicode.)<p>> Ability to declare dependencies as Git URLS with commit locking (can provide a tag or sha1).<p>Providing a hash is helpful for security, although keeping a copy of the dependencies would also help, and you can access any copy of it; this way you do not need an internet connection (or even if you do, in case the connection is down, etc). Having multiple sources to find the dependencies is helpful, and if hashes are available for the files that it depends on then you can verify that it is the correct file.<p>> C style comments.<p>Depending on the syntax of what tokens would make sense together, it might not be the best idea (although this depends on what the syntax of Zig otherwise is; it might not be a problem). In C, a slash followed by an asterisk denotes the beginning of a block comment, but a slash also means division, and an asterisk as a unary operator denotes dereferencing; this is a sensible combination, so a space or parentheses or [0] or something else like that would be required in order to not be treated as a comment. This is a bad idea in C; I don't know enough about Zig to know how well it works in Zig, though.<p>> Shebang line OK so language can be used for "scripting" as well.<p>This is also something to be considered depending how the rest of the syntax works. It is probably a good idea though, if it does not interfere with other syntax like the comments in C interferes with the syntax of the operators in C.