With the removal of cImport using simple things like strftime from the c stdlib has been forced to become more intentional, which breaks the ergonomics of the modularity of some of my hobby projects. This makes the limitations of the zig stdlib much more noticeable to me. Obviously there are packages for this- but my personal experience is that a lot of package use for small things, that in some languages would be in the std, becomes a tangled NPM-like web. It can also go the other direction where Go’s is very large. I think one approach(though from my understanding is not going to happen because of the reasoning of removing cImport in the first place) to limit the overhead of maintenance would be treating cstdlib as essentially a 2nd class stdlib.
The short answer is “No”, assuming “a language std” means having datetime formatting in the standard library ( if you want datetime to be part of the language, then the answer if “Definitely not”).
I might be mistaken, but as I understood it, the std library as it is now, is what is needed for supporting the Zig compiler itself. That doesn’t preclude that once the language is stable, and with it the std lib is stable, there won’t be room for adding basic functionality, but until then I should not try and hold my breath waiting for functionality.
If things get removed from std, and not replaced because they are not used by the compiler, or when things are not available in the first place, that can be annoying and/or time consuming. But the upside is that the core team doesn’t have to worry, when implementing writergate, juicy main, etc to have to upgrade unused (from the core teams perspective) code while the compiler is still being developed towards 1.0 (and last time I looked it still was).
I have worked with Python for 30 years, and from my start with it, the standard library was relatively extensive. There where also additions to the standard library by core (Python) team members without appropriate test coverage. At least in one occasion I was happy to have my own implementation (of ordereddict in C), instead of having to rely on the version added to the standard library, that would crash your program (until the next minor release).
Hasn’t been true since Zig implemented user space async in the std
Already happening with the removal of std.posix from the std
How is this untrue?
If you just look at InternPool you will see std.Io used in many functions.
just to note: you don’t need cImport to use strftime. you can write
size_t strftime(char *s, size_t max, const char *format,
const struct tm *tm);
const TM_t = extern struct {
// ...
};
extern fn strftime(
s: [*]u8,
max: usize,
format: [*:0]const u8,
tm: *const struct TM_t
) callconv(.c) usize;
Do you feel like you need permisson to write a PR to std.time.epoch ?
Oh thanks for pointing that out, thought my understanding is still there wouldn’t be a way to cDefine right?
One expanding the feature set this much, yes.
As in, defining via cDefine a macro that the libc headers will take into account? Yeah, I have some ideas, but none of them are great.
If you’re compiling a C library that is linked into your Zig code, of course you can add arbitrary macros by either including a header into the compilation or using cflags.
Or if you are confident about the ramifications of your definition, you could make its Zig equivalent and write out the resulting Ziggified declarations yourself. I don’t suggest this tho, lol, it sounds difficult in the case of a preprocessor-happy environment like the libc headers and may not be portable.
Yeah, I think parsing strings into a valid datetime representation and then formatting them back out, as well as basic operations around datetimes is important for a standard library. Otherwise, you generally end up with multiple third party solutions.
I wouldn’t want Zig to end up in the place where Go is, where a single project with a few dependencies end up taking on multiple JSON parsers, for example.
I don’t know if this is the expressed goal, or ever was, but the stdlib has gpu related stuff, a cli progress bar implementation, .tar handling, http methods, and now an attempted async IO abstraction layer. I have my opinions about this as I’m sure others do (in both directions!) but it certainly is what it is at this point. A datetime fmt seems quite conservative compared to a lot of the stuff atm (to me!).
std.Io is used in many functions because its the standard libraries Io interface, not because the compiler etc. requires async. If the line of argument is “stdlib only has stuff the compiler uses” and “the compiler uses whatever stdlibs file interface is” then any conceivable file interface you can come up with is tautologically supported by that line of argument.
Of course I am not well acquainted with zig internals, I could be wrong about everything.
the stdlib has gpu related stuff, a cli progress bar implementation, .tar handling, http methods, and now an attempted async IO abstraction layer
All of those are used by the compiler and the package manager. std.gpu is there because SPIR-V is a supported target I’m guessing?
Date/Time functionality falls in the same bucket as full Unicode support probably – the scope of possible functionality to include is huge, so why not just have the stuff that the compiler needs in there and leave the rest to 3rd party libraries.
Right, I forgot about that. Again though, I’m sure the compiler has tons of code it reuses that isn’t in the stdlib, so this all remains somewhat arbitrary imho (not referring to gpu specifically here, to be clear).
I’m not talking about the Io interface more generally, I’m talking about specifically async. Are io.async and Futures used in the compiler?