Skip to content

Conversation

IOKG04
Copy link
Contributor

@IOKG04 IOKG04 commented Sep 19, 2025

Similarly to what #25260 did with fmt.bufPrintZ, I replaced mem.Allocator.dupeZ and mem.orderZ with more generic Sentinel versions, so they can be re-used more.

Since most of the *Z functions are there to interact with the operating system/c code (ex. posix.mkdirZ), I didn't change those.

One I did consider changing was mem.joinZ, though in my opinion it'd be worth completely reworking it (and mem.join), so it doesn't only work on []u8s, but on any slice type.
I can do that in this PR too, though some help for naming would be appreciated, cause the join functions as they exist currently should be kept and just marked deprecated, but the new, generic functions should also have fitting names.

closes #25285
also fixes one of the issues described in #22618

@neoto
Copy link

neoto commented Sep 19, 2025

I agree that having more flexibility is a good thing, but I disagree with deprecating the *Z methods simply because null-terminated arrays are overwhelmingly more common compared to anything else. Forcing everyone to adapt their usages feels like prioritizing some kind of theoretical flexibility over well-established usability.

@IOKG04
Copy link
Contributor Author

IOKG04 commented Sep 19, 2025

I too would say that 0-terminated arrays/slices are way more common than all others combined, but as the zen says:

Only one obvious way to do things.

@rohlem
Copy link
Contributor

rohlem commented Sep 20, 2025

as the zen says:

Only one obvious way to do things.

Just my 2c, maintainers have to decide, but so far I've seen "one obvious way" to mean "one easily-decidable way", not "only one way at all".
So if you know you're dealing with 0-termination, the -Z functions (which may just call the -Sentinel functions) are the obvious choice,
otherwise you call the -Sentinel functions.
There's always an obvious answer, so it doesn't violate the zen imo.

As another example, std.mem contains both indexOf for searching the entire input and indexOfPos for starting from a certain position.
If we wanted only one way, all indexOf(T, a, b) should be replaced by indexOfPos(T, a, 0, b) (and we could drop -Pos from the name).
But if a call site always starts at 0, the one obvious way is to use indexOf instead of hardcoding the 0. So having both still fits the zen imo.

@GrayHatter
Copy link
Contributor

The advice I was given was that The Zig Zen is descriptive, not prescriptive.

Thus, you should avoid arguments that cite or reference it. Code should stand on it's own merits and it's own arguments, if the only rational or reason for a change is "it feels more like the zig zen to me" it really has no compelling reasons at all.

In this case, while I would have preferred fnNameZ (still taking an explicit Sentinel arg) over fnNameSentinel for all of the above, (shorter names are often better, (especially when you're dyslexic, (sentinel is not a kind word to me))), but a unified style is much more important; and there's a few existing diffs that have already adopted the Sentinel postfix. It would be really nice not to have to remember if I'm supposed to type Z, or Sentinel for each specific namespace.

@IOKG04 IOKG04 force-pushed the Sentinel-instead-of-Z branch from c917ff5 to d165f17 Compare September 26, 2025 18:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

std.mem.Allocator dupeZ to dupeSentinel
4 participants