rename std.os to std.posix

[andrewrk]

std.os.windows and similar will remain the same, but everything else, e.g. std.os.write would become std.posix.write.

[anosovic]

why do we want the posix namespace by itself and not under os?

[karrick]

Is there merit to having a OS agnostic library, which makes calls into posix and window libraries?

That way most programmers can write OS agnostic code, and standard library writers can focus on how to implement that code using both posix and windows sub-libraries?

[andrewrk]

Is there merit to having a OS agnostic library

All of the std lib is OS agnostic except what is namespaced under std.os

[Flaminator]

All of the std lib is OS agnostic except what is namespaced under std.os
Will this still be that case after moving the POSIX parts from std.os to std.posix or will that statement move to also include what is namespaced under std.posix? As POSIX isn't os agnostic.

[kubkon]

All of the std lib is OS agnostic except what is namespaced under std.os
Will this still be that case after moving the POSIX parts from std.os to std.posix or will that statement move to also include what is namespaced under std.posix? As POSIX isn't os agnostic.

@andrewrk might correct me here but I guess std.posix wouldn't be platform agnostic in its entirety, although for the most part we could probably successfully emulate POSIX behaviour in say Windows for example (with a few exceptions ofc). In fact, I'd imagine that with #1840 landing, we'd get really close to achieving that goal since hooking directly into NT API seems to offer a lot more flexibility plus it does allow for something close to *at syscalls you'd normally find in POSIX.

[Flaminator]

@kubkon I know I am no authority when it comes to stuff like this but I don’t really think trying to emulate POSIX behaviour on non-POSIX platforms is a good or a preferable thing. It might make it easier in someways but mostly towards one group.

I have noticed over the last 10-15 years with all these new languages popping up that most of these languages are primarily developed by people that use Linux or a different Unix-like operating system. Which of course means that a lot of the interfaces, apis and tooling are heavily focussed on POSIX ideas of how things work and should work. This brings some annoyances to users on operating systems like Windows where things just work differently. I have seen it happen in Go, Rust, the filesystem api in C++ and even in some places in Zig.

[andrewrk]

Emulating POSIX behavior on non-POSIX platforms is not an explicit goal of the Zig standard library. We have first-class Windows-specific API, as well as first-class Windows support in the main cross-platform abstractions. The POSIX API layer is mostly an implementation detail that seems reasonable to expose as a public API. I say implementation detail, because many systems have the exact same POSIX API, and so the main cross-platform abstractions look something like:

if os does not have the common posix API
   do the specific logic for this os
else
   do the posix API layer

As you can imagine the top half of that if statement is often Windows. Now, consider something simple like std.posix.exit. We can either put specific logic in there to make it a compile error if you try to use the POSIX exit function on Windows, but... it's even easier to just make it work, by making it call std.windows.ExitProcess on Windows. ...and then it turns out a lot of the other posix functions are pretty easy to implement in Windows, just by forwarding the posix API layer to the Windows API layer. That being said, there are plenty of posix layer functions that do not even attempt this; they just emit a compile error saying the function is not available for Windows.

Anyway, as far as your concerns for Windows not being taken into account for designing the main cross platform API abstractions, I share your concerns. And I am guilty of using Linux as my main dev workstation, although I do have a dedicated Windows laptop and a dedicated macOS laptop. Zig's main cross platform abstractions (std.fs, std.process, etc) are intended to support all operating systems optimally. This means in some cases clever conditional compilation that makes things Just Work - there is a lot of this going on that I am quite proud of, especially the code @kubkon has been working on recently - and in some cases it means pushing a bit of the complexity back on to the programmer.

[jayschwa]

How will this affect BYOOS integrations? Will we be exporting root.posix rather than root.os?

[andrewrk]

BYOOS integrations need some reworking. Right now they are not even at the posix abstraction level- they are at the same layer as libc (which is problematic). I think we need to reevaluate the best way to satisfy the BYOOS use case and improve the way integration works. It's possible that looks like exporting root.posix rather than root.os but it may be worth considering even another option (which I haven't thought of yet).

[tadeokondrak]

This isn't a very important detail, but I think it should be named unix, not posix.
I think posix would imply that code using it would compile on any system that implements the POSIX standard, but that isn't the case.
unix is a more generic term.

[andrewrk]

Un-accepting for reconsideration in light of #6600

[MarcTCruz]

A name anything like std.cross.os, std.cross, std.os.cross shows better intention, if its design is posix, windows or a zig one is a detail.
Lots of developers choose new languages, due to its facility on writing compatible, equal, and well defined results between cross systems, without the need to reimplement different pieces of code to do the same for different oses.

[chrboesch]

Thanks, I find std.process.exit() much clearer than std.os.exit(). After all, I'm not shutting down the operating system itself.