If it isn't obvious, the problem is that you can't indent them properly because the indentation becomes part of the string itself.
Some languages have magical "removed the indent" modes for strings (e.g. YAML) but they generally suck and just add confusion. This syntax is quite clear (at least with respect to indentation; not sure about the trailing newline - where does the string end exactly?).
" one\n"
" two\n"
" three\n"Snippet from my shader compiler tests (the `\` vs `/` in the paths in params and output is intentional, when compiled it will generate escape errors so I'm prodded to make everything `/`):
test "shader_root_gen" {
const expected =
\\// Generated file!
\\
\\pub const @"spriteszzz" = opaque {
\\ pub const @"quadsprite" = @import("src\spriteszzz/quadsprite.glsl");
\\};
\\
\\pub const @"sprites" = opaque {
\\ pub const @"universalsprite" = @import("src\sprites/universalsprite.glsl");
\\};
\\
\\pub const @"simpleshader" = @import("src/simpleshader.glsl");
\\
;
const cmdline =
\\--prefix src -o testfile.zig src\spriteszzz/quadsprite.glsl src\sprites/universalsprite.glsl src/simpleshader.glsl
;
var args_iter = std.mem.tokenizeScalar(u8, cmdline, ' ');
const params = try Params.parseFromCmdLineArgs(&args_iter);
var buffer: [expected.len * 2]u8 = undefined;
var stream = std.io.fixedBufferStream(buffer[0..]);
try generateSource(stream.writer().any(), params.input_files.items, params.prefix);
const actual = stream.getWritten();
try std.testing.expectEqualSlices(u8, expected, actual);
} `A
simple
formatted
string
`
?A\n\tsimple\n\t\tformatted\n\t\t\tstring\n\t
If you wanted it without the additional indentation, you’d need to use a function to strip that out. Typescript has dedent which goes in front of the template string, for example. I guess in Zig that’s not necessary which is nice.
fn main() {
if something {
print(`A
simple
formatted
string`)
}
}
I would so much rather read and write:
let x = """
a
multiline string
example
"""
let x =
//a
//multiline string
//example
;
Here is a simple way to implement the former case: require tabs for indentation. Parse with recursive descent where the signature is
(source: string, index: number, indent: number, env: comp_env) => ast
This can be implemented in under 200 lines of pure lua with no standard library functions except string.byte and string.sub.
It is common to hear complaints about languages that have syntactically significant whitespace. I think a lot of the complaints are fair when the language does not have strict formatting rules: python and scala come to mind as examples that do badly with this. With scala, practically everyone ends up using scalafmt which slows down their build considerably because the language is way too permissive in what it allows. Yaml is another great example of significant whitespace done poorly because it is too permissive. When done strictly, I find that a language with significant whitespace will always be more compact and thus, in my opinion, more readable than one that does not use it.
I would never use zig directly because I do not like its syntax even if many people do. If I was mandated to use it, I would spend an afternoon writing a transpiler that would probably be 2-10x faster than the zig compiler for the same program so the overhead of avoiding their decisions I disagree with are negligible.
Of course from this perspective, zig offers me no value. There is nothing I can do with zig that I can't do with c so I'd prefer it as a target language. Most code does not need to be optimized, but for the small amount that does, transpiling to c gives me access to almost everything I need in llvm. If there is something I can't get from c out of llvm (which seems highly unlikely), I can transpile to llvm instead.
I would have probably gone with ` or something.
.. it is using \\
It’s some sort of mental glitch that a number of people fall into and I have absolutely no idea why.
Choice of specific line-start marker aside, I think this is the best solution to the indented-string problem I've seen so far.
> In text blocks, the leftmost non-whitespace character on any of the lines or the leftmost closing delimiter defines where meaningful white space begins.
From https://blogs.oracle.com/javamagazine/post/text-blocks-come-...
It's not a bad option but it does mean you can't have text where every line is indented. This isn't uncommon - e.g. think about code generation of a function body.
spoken as someone who found the syntax offensive when I first learned it.
Usually, representing multiline strings within another multiline string requires lots of non-trivial escaping. This is what this example is about: no escaping and no indent nursery needed in Zig.
Makes cut 'n' paste embedded shader code, assembly, javascript so much easier to add, and more readable imo. For something like a regular expressions I really liked Golang's back tick 'raw string' syntax.
In Zig I find myself doing an @embedFile to avoid the '\\' pollution.
const still_raw =
"const raw =
" "Roses are red
" " Violets are blue,
" "Sugar is sweet
" " And so are you.
" "
";
"
;
const raw =
"He said "Hello"
"to me
;
1. from the user's point of view, you can now have multiline string literals that are properly indented based on their surrounding source code, without the leading spaces being treated as part of the string
2. from an implementation point of view having them parsed as individual lines is very elegant, it makes newline characters in the code unambiguous and context independent. they always break up tokens in the code, regardless of whether they are in a string literal or not.
People are having trouble distinguishing between '//' and '\\'.