4 ms·

Zig is great, but &[_][]const u8 a really painful type signature to type repeatedly every time you want to handle strings. I know it's a small thing but string

Zig is great, but &[_][]const u8 a really painful type signature to type repeatedly every time you want to handle strings. I know it's a small thing but strings are common enough that the little ergonomic costs add up.

eperdew 5y ago
Agreed. I alleviated this in my last zig project by just declaring a type alias, however. Strings could use some nice support from the stdlib once it gets fleshed out.
Jarred 5y ago
I globally import this via usingnamespace: pub const string = []const u8; This lets me do: &[_]string{“hi”} A little better, but not great.
AndyKelley 5y ago
the lines in question: const fuzz_exe_path = try std.fs.path.join(b.allocator, &[_][]const u8{ b.cache_root, fuzz_executable_name }); // We want `afl-clang-lto -o path/to/output path/to/object.o` const fuzz_compile = b.addSystemCommand(&[_][]const u8{ "afl-clang-lto", "-o" }); can be updated to newer syntax: const fuzz_exe_path = try std.fs.path.join(b.allocator, &.{ b.cache_root, fuzz_executable_name }); // We want `afl-clang-lto -o path/to/output path/to/object.o` const fuzz_compile = b.addSystemCommand(&.{ "afl-clang-lto", "-o" }); docs: https://ziglang.org/documentation/master/#Anonymous-List-Literals https://ziglang.org/documentation/master/#Anonymous-List-Lit... added in zig 0.6.0: https://ziglang.org/download/0.6.0/release-notes.html#Tuples-Added-Var-Args-Removed https://ziglang.org/download/0.6.0/release-notes.html#Tuples...
- squeek502 5y ago
  Nice, didn't know list literals could be used for that. Makes sense, though.
pjmlp 5y ago
What puts me off are the JavaScript pre-modules way to do Zig modules, I already have Objective-C for @ everywhere, and it is just like C in regards to use-after-free.
flohofwoe 5y ago
The string part of this is just "[]const u8", which is somewhat similar to "const char*" in C (except that [] is a slice and also holds the string literal's length). IMHO for a systems programming language it's the right decision to not have a builtin string type (and instead treat strings as bags of bytes), proper string support is better provided by a library (or even better several specialized string processing libraries).
- tialaramex 5y ago
  I would have agreed with this before I saw Rust's built-in str and thus &str. Obviously Zig isn't going to offer what Rust does here because it involves safety guarantees, but the assumption could be exactly the same, this is a UTF-8 string, and even in systems programming that's a valuable built-in. Twenty years ago it's unclear what you should pick here, and so "bytes" ends up being a reasonable compromise. But today it isn't unclear, the answer will be UTF-8. Languages like C++ are stuck offering people a 16-bit character type if they want one because they were around in the 1990s when that seemed potentially viable and they're stuck in a compatibility quagmire, not because it is any actual use today.
  - flohofwoe 5y ago
    Hmm.... I may miss some details, but Rust's str isn't that much different from a type wrapper const str = []const u8; ...in Zig isn't it? Both are slices (aka pointer/size pairs). Rust's str seems to have some additional string-related functions, but in Zig those could be provided in the stdlib (along with the 'str' type wrapper), and then on the next level a String-like type which includes memory management. PS: Ah ok, one important difference is that Rust's str is guaranteed to be valid UTF-8.
    - tialaramex 5y ago
      I'll take your word on it that writing const str = []const u8; would be equivalent, however, I think that's already valuable to build in considering how much people use string literals. You're correct that Rust has a bunch of actual type rules here to say that a str really is UTF-8 and not some random bytes -- and Zig presumably wouldn't do that, but by explicitly building in a named str type, rather than just shrugging and saying []const u8, there'd at least be a social convention that str is actually, you know, a UTF-8 string, not just some bytes. And yes, obviously the memory managing high level String with features like concatenation and mutability is way more heavyweight and shouldn't be built-in to the language fundamentals of something like Zig, it's just the cheap "size + pointer" immutable string slice that I believe is worth building in explicitly now that I've seen Rust do it and after decades of experience noticing that software almost invariably has string literals representing human text (thus suitable for UTF-8) that we shouldn't muddle with slices of arbitrary bytes.

eperdew 5y ago

Agreed. I alleviated this in my last zig project by just declaring a type alias, however. Strings could use some nice support from the stdlib once it gets fleshed out.

Jarred 5y ago

I globally import this via usingnamespace: pub const string = []const u8; This lets me do: &[_]string{“hi”} A little better, but not great.

AndyKelley 5y ago

the lines in question: const fuzz_exe_path = try std.fs.path.join(b.allocator, &[_][]const u8{ b.cache_root, fuzz_executable_name }); // We want `afl-clang-lto -o path/to/output path/to/object.o` const fuzz_compile = b.addSystemCommand(&[_][]const u8{ "afl-clang-lto", "-o" }); can be updated to newer syntax: const fuzz_exe_path = try std.fs.path.join(b.allocator, &.{ b.cache_root, fuzz_executable_name }); // We want `afl-clang-lto -o path/to/output path/to/object.o` const fuzz_compile = b.addSystemCommand(&.{ "afl-clang-lto", "-o" }); docs: https://ziglang.org/documentation/master/#Anonymous-List-Literals https://ziglang.org/documentation/master/#Anonymous-List-Lit... added in zig 0.6.0: https://ziglang.org/download/0.6.0/release-notes.html#Tuples-Added-Var-Args-Removed https://ziglang.org/download/0.6.0/release-notes.html#Tuples...

squeek502 5y ago
Nice, didn't know list literals could be used for that. Makes sense, though.

pjmlp 5y ago

What puts me off are the JavaScript pre-modules way to do Zig modules, I already have Objective-C for @ everywhere, and it is just like C in regards to use-after-free.

flohofwoe 5y ago

The string part of this is just "[]const u8", which is somewhat similar to "const char*" in C (except that [] is a slice and also holds the string literal's length). IMHO for a systems programming language it's the right decision to not have a builtin string type (and instead treat strings as bags of bytes), proper string support is better provided by a library (or even better several specialized string processing libraries).

tialaramex 5y ago
I would have agreed with this before I saw Rust's built-in str and thus &str. Obviously Zig isn't going to offer what Rust does here because it involves safety guarantees, but the assumption could be exactly the same, this is a UTF-8 string, and even in systems programming that's a valuable built-in. Twenty years ago it's unclear what you should pick here, and so "bytes" ends up being a reasonable compromise. But today it isn't unclear, the answer will be UTF-8. Languages like C++ are stuck offering people a 16-bit character type if they want one because they were around in the 1990s when that seemed potentially viable and they're stuck in a compatibility quagmire, not because it is any actual use today.
- flohofwoe 5y ago
  Hmm.... I may miss some details, but Rust's str isn't that much different from a type wrapper const str = []const u8; ...in Zig isn't it? Both are slices (aka pointer/size pairs). Rust's str seems to have some additional string-related functions, but in Zig those could be provided in the stdlib (along with the 'str' type wrapper), and then on the next level a String-like type which includes memory management. PS: Ah ok, one important difference is that Rust's str is guaranteed to be valid UTF-8.
  - tialaramex 5y ago
    I'll take your word on it that writing const str = []const u8; would be equivalent, however, I think that's already valuable to build in considering how much people use string literals. You're correct that Rust has a bunch of actual type rules here to say that a str really is UTF-8 and not some random bytes -- and Zig presumably wouldn't do that, but by explicitly building in a named str type, rather than just shrugging and saying []const u8, there'd at least be a social convention that str is actually, you know, a UTF-8 string, not just some bytes. And yes, obviously the memory managing high level String with features like concatenation and mutability is way more heavyweight and shouldn't be built-in to the language fundamentals of something like Zig, it's just the cheap "size + pointer" immutable string slice that I believe is worth building in explicitly now that I've seen Rust do it and after decades of experience noticing that software almost invariably has string literals representing human text (thus suitable for UTF-8) that we shouldn't muddle with slices of arbitrary bytes.