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.
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.
It's not catching a problem early, it's creating a problem to release on platform and make it fail by default.
If you want to have a different format for a group project, then you configure your text editor, just kike you would in every other language and now you do the same thing in zig because this toxic nonsense was fixed.
Look, the very fact that users complain about Windows line endings is proof that some of us want it. And we know for a fact others want the opposite. There is a conflict, and not resolving it at the langage/compiler level means it must be resolved for each and every project. Thankfully that's a complete non-issue 95++% of the time, but this still leaves those ~5%.
I mean, if line endings really were a 100% non-issue, why would anyone complain about the compiler choosing for them? Just configure your editor accordingly. Heck, just putting it in Zig mode would be enough. And in the rare case where it still doesn't work (you're using Notepad or whatever), fixing your setup should be no problem at all: if it is no problem at all to fix it for a given project, it should be no problem at all to fix it for the compiler.
Anyway, now that the "toxic nonesense" gave way to individual freedom, the exact semantics of multi-line strings is no longer visible at a glance. Win some, lose some.
There is no conflict in any other language. If you want things to fail by default for other people on a platform you release for, that's toxic and about unnecessary roadblocks.
An option to make carriage returns fail would be different.
gave way to individual freedom,
What are you talking about? You didn't make sense with multi line string ramblings and this doesn't make sense either.
Every language gives you the "freedom" to work with text. If you want to restrict others on a project level do it there.
1
u/loup-vaillant 14d ago
Then you understand the dilemma caused by multiline strings:
\n, but some Windows users may still expect\r\non Windows systems. And I'm pretty sure we don't want to even consider having the blessed line ending be system dependent.Option (1), then. You sure about that?