<zags>
not gonna lie, i miss smart pointers :) i think someone had been pondering about that for zig, but not sure how well that could work without destructors to release at end of scope/lifetime
montezuma has joined #zig
plumm has quit [Ping timeout: 240 seconds]
plumm has joined #zig
zags has quit [Ping timeout: 246 seconds]
geemili has joined #zig
n0tekky has quit [Read error: Connection reset by peer]
montezuma has quit [Quit: WeeChat 2.8]
plumm has quit [Ping timeout: 264 seconds]
plumm has joined #zig
kbd has joined #zig
<kbd>
Dumb question: How do I compare a null-terminated string? `std.mem.eql(u8, os.argv[1], "...")` doesn't work, what's the right type over u8?
cole-h has joined #zig
<daurnimator>
kbd: usually get a null terminated slice first. see std.mem.spanZ
<kbd>
that works, thanks. I don't understand why though. Most of my "wasted" time learning Zig is just trying to get the types of slices/arrays/strings right.
<daurnimator>
in C when you get it wrong it silently works except you have a security hole. zig *makes* you think about it
braket has joined #zig
<daurnimator>
kbd: you may also use `std.cstr.eql` instead of `std.mem.eql`
<daurnimator>
uh,. std.cstr.cmp
<kbd>
thanks again daurnimator
gazler has joined #zig
gazler_ has quit [Ping timeout: 240 seconds]
<kbd>
thanks again daurnimator
<kbd>
whoops alt tab + up arrow enter went to the wrong window 🤦‍♂️
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
plumm has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
<braket>
Is there a name for the data types that can be constructed with `T{}`? Trying to update some docs but I'm blanking on what to call them.
<g-w1>
struct
<g-w1>
b
<g-w1>
sorry
kbd has joined #zig
kbd has quit [Client Quit]
craigo has joined #zig
earnestly has quit [Ping timeout: 265 seconds]
kbd has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<kbd>
What's the stance on high level command line argument parsing in the stdlib? Just needs to be written, or out of scope?
<g-w1>
zig-clap is out there, although there seems to be a sentiment that you should roll your own out of simplicity
yeti has quit [Quit: WeeChat 3.0]
yeti has joined #zig
yeti has quit [Read error: Connection reset by peer]
yeti has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<braket>
g-w1 arrays, enums, and unions also use T{} though
<tdeo>
i don't think enums do
<braket>
ah, you're right, not enums
plumm has joined #zig
kbd has joined #zig
plumm has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
v0idify has quit [Ping timeout: 268 seconds]
v0idify has joined #zig
leon-p has quit [Quit: leaving]
Biolunar has joined #zig
ncon has quit [Remote host closed the connection]
ncon has joined #zig
jokoon has joined #zig
sord937 has joined #zig
braket has quit [Ping timeout: 265 seconds]
gazler_ has joined #zig
gazler has quit [Ping timeout: 240 seconds]
xackus has joined #zig
zags has joined #zig
teratorn has quit [Quit: quit]
teratorn has joined #zig
ky0ko has quit [Read error: Connection reset by peer]
ky0ko has joined #zig
<zags>
is there a way to build types in a staggered fashion at compile time? For instance, call various functions that add fields to a struct to produce the final type.
<ikskuh>
heya o/
<ikskuh>
zags: you can build yourself a struct builder :)
<ikskuh>
shouldn't be that much of work actually
<ikskuh>
nice thing with comptime is that you can just append stuff to slices with ++
<zags>
what's the ingredients of a struct builder? Note that this is exposed to the user side, so x.a().b().doit(), so only after b() is the type known
<zags>
(x is a type, not a runtime variable)
<zags>
aha, std.meta have the ingredients, interesting
<zags>
type { … }, how does the actual finalization step work?
<ikskuh>
@Type()
<ikskuh>
std.builtin, sorry
<ikskuh>
not std.meta
<ikskuh>
note that a builder interface isn't typical zig style
<zags>
I'm disregarding that in this case
<zags>
I have a functional-style streams api going, and those typically have fluid api style, which I like so that's what'll be :)
<zags>
Building the stream pipeline at compiletime will make it completely free of heap allocations, so I wanna look into that.
<zags>
ok, must be just a bad compiler error then, it claims I'm returning "slice"
<zags>
probably have some error elsewhere
<ikskuh>
code snippet?
<zags>
nah, it's a big mess, i'll try to sort it knowing it's supposed to work, will make a testcase if I can't :D
<ikskuh>
are you maybe passing in a string?
<ikskuh>
something("foo")
<zags>
oof, was returning the wrong thing, was just a confusing error message.
<zags>
out of curiosity, is it safe, like in c++, to self destruct? Basically alloc.free(self). Any by safe, I mean under the assumption the struct was allocated with the same allocator haha.
<ikskuh>
sure
<ikskuh>
there is no *this* ;)
<ikskuh>
no concept of "self"
<ikskuh>
there is only functions, arguments and values :)
<zags>
yeah, no hidden machinery at all, should be safe then
<ikskuh>
"self-destruct" is actually pretty common over all stdlib
<zags>
I see, good to know
posixlix has joined #zig
<posixlix>
Hey everyone! Is there a well-defined way of accessing a tagged union's tag and payload? (Basically this issue, https://github.com/ziglang/zig/issues/3641, but I really would prefer to not incur the runtime cost of the other options, even if it's just a few cmp instructions.)
<posixlix>
I made a hack that allows me to do the aforementioned, but it would very quickly become invalidated with any change to tagged unions' layout and probably doesn't account for some edge cases anyway.
<posixlix>
(To clarify, I want to initialize a tagged union with a runtime-known tag value)