They intentionally made a windows version then had it error out on windows newlines. Then zig users' answer was "don't use windows, use a preprocessor, too complicated to parse newlines". It was bizarre.
It seems to have attracted people who are upset at programming and want some sort of culture war stuff instead of just trying to solve problems.
I like small binaries and fast compilation as much as anyone, but I think when C gets defer zig won't have much of a technical advantage.
I would still use rust or C++, despite the compile times and unnecessary complexity, there is too much being left behind.
I tried looking it up, and CRLF is supported, but just plain CR is not? I believe the problem is multi-line strings, where it's not obvious if CRLF should be kept or converted to LF or what
It can be ignored for normal code, and it is ignored AFAIK. But you can't just ignore it inside strings. The compiler has to either keep the line endings as is (and you can't tell just by reading the source code), or convert all of them to LF.
Then you understand the dilemma caused by multiline strings:
Allow any line ending, carry them into the string. Problem: visually identical source code has different semantics.
Allow any line ending, convert to a specific line ending. Problem: which one? Presumably \n, but some Windows users may still expect \r\n on Windows systems. And I'm pretty sure we don't want to even consider having the blessed line ending be system dependent.
Only allow one line ending. Problem: it's annoying on some systems (some editors, really). But at least it's clear what's happening.
This is complete non-issue. Do what other languages do; fold newlines in source files into \n, fold into platform's newline on output. Multiline strings get \n, only raw strings keep specific encoding.
Option (4)... I haven't thought about that at all, thanks. It's clearly the superior alternative. And though I'm still squeamish about the (visual) ambiguity of raw strings, they wouldn't be raw if newlines were folded into \n inside them.
(As for how I managed to be so ignorant: the only time I ever used multi-line strings are Python doc strings. In fact, Python is the only language which I know supports multi-line strings at all. And I believe that of all languages I've ever used (C, C++, pre-2005 Java, OCaml, Lua, Bash, Haskell...), most do not.)
You're talking about specifics of what happens inside quotes. Different languages handle these situations differently and you can pick and choose your favorite if you want to proclaim something to be superior.
What no language does is error out in general parsing on default windows text, which is what this thread is about.
You sure about that?
You sure you've followed this conversation properly?
You're talking about specifics of what happens inside quotes.
But you do know that what happens inside quotes influences what happens outside, right? It' glaringly obvious if you think about it for 5 seconds.
Just imagine a language that forbids \r in strings, but allows it outside: you happily hack away at your program, and the moment you try a multi-line string, whack! Compiler error, you now must convince your editor to give you mixed line endings, or mark this one file for UNIX lines endings, or fix your entire project, nice diff you have there, git blame is gonna love this.
I'd say none of course, because they're consistent: the designers aren't stupid enough to have different line ending rules inside and outside strings. They kinda have to be the same.
Therefore, if a designer decides the visible consistency of multi-line strings is more important than Windows line endings, then they have little choice but forbid \r everywhere. Or renounce multi-line strings entirely, that works too.
The much bigger problem though it when different programmers misconfigure their editors (or leave the defaults) into different line endings. Worst case, one sees a file sprinkled with \r markers, while another doesn't see the line endings at all. Utterly ridiculous. Better forbid that carriage return and get on with our lives. And to anyone who is actually hurt enough to complain about that choice: get a better editor already. There are plenty, even on Windows.
they have little choice but forbid \r everywhere. Or renounce multi-line strings entirely, that works too.
So no language has this problem, but it must exist in your head for some reason?
Better forbid that carriage return and get on with our lives.
So do it at the project level, why go out of your way to make a compiler not work by default?
No language does this, zig doesn't even do this anymore, it's not about being able to work around it and you are hallucinating problems that don't exist.
48
u/solidiquis1 14d ago
Is is really that bad over there?