std.cstr: deprecate namespace
Can you provide some rationale for these changes? I personally prefer status quo.
Can you provide some rationale for these changes? I personally prefer status quo.
addNullByte does exactly same thing as allocator.dupeZ (literally equal line-by-line, but latter name shows cloning effect more clearly), line_sep doesn't sound as something that should belong in "c string" namespace (and does not indicate clearly that it depends on OS, unlike .native, also Unicode defines own set of end-of-line indicators, so we might want to add std.unicode.end_of_line in the future, that's why line_sep was moved to std.ascii), and NullTerminated2DArray is not used anywhere in this repository (and other repositories according to sourcegraph and github search, but I don't have strong feelings for this one, so I don't mind if you'd revert it).
I like these changes, I'm not sure cstr has a good reason to exist tbh. Sentinel terminated pointers are a native zig type and functions to make working with them easier belong in std.mem in my opinion.
Perhaps it is reasonable to have a compatibility function matching libc's strcmp, but I think that would make more sense as std.c.strcmp() than the current std.cstr.cmp().
Tangentially I think we may want an idiomatic Zig function for comparing sentinel terminated pointers as it could likely be faster than std.mem.eql(u8, std.mem.sliceTo(a, 0), std.mem.sliceTo(b, 0)) in many cases where the "strings" are not equal and iteration to find the sentinel can be aborted.
OK, I actually agree with all of that. I think my only issue is with the new public namespace names chosen:
-
std.ascii.end_of_line.cr_lf -
std.ascii.end_of_line.lf -
std.ascii.end_of_line.native
Previously we had:
-
std.cstr.line_sep
Looking at all the places line_sep was used, I think that API should actually be eliminated. In these places, the kind of newline used had more to do with the specifics of the callsite than on what target OS the zig code was being compiled for.
So, I am in favor of these changes, provided that this additional thing is done:
- Remove
std.ascii.end_of_lineentirely.
A follow-up commit to fully eliminate std.cstr would be appreciated.
Thank you for reviews, they definitely improved quality a lot...