ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<wirelyre>
and I guess LTO would be handled by producing a single artifact from all Zig code
<wirelyre>
man, writing a linker is hard
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
geemili has joined #zig
wirelyre has left #zig [#zig]
<andrewrk>
daurnimator, c pointers are represented as optional pointers, with the optional syntax
<andrewrk>
daurnimator, there's no concept of "truthyness". the only thing allowed in if conditions is boolean values, which can be either true or false
<andrewrk>
so I guess you could say, truthyness is defined like this: true is true, and false is false
<daurnimator>
andrewrk: okay, so `if (thing_that_returns_null())` is a compile error?
<andrewrk>
if there's a |x| payload in the then body, it's different syntactically, and it expects an optional value
<andrewrk>
likewile if there's an |e| payload in the else body, it's different syntactically, and it expects an error union value
<andrewrk>
*likewise.
<andrewrk>
same goes for while
<jfondren>
the classic = vs. == bug is also defeated by assignment evaluating to void
<daurnimator>
okay, thanks
<andrewrk>
right. more generally, it's intentionally difficult for typos to be syntactically & semantically meaningful
<daurnimator>
new question: how does zig work with setjmp/longjmp? does it rely on unwinding?
<andrewrk>
it works the same way C does
<andrewrk>
and it's recommended to not use setjmp/longjmp
<daurnimator>
and interoperates with C happily?
<daurnimator>
e.g. can I have a stack that does: C (setjmp) -> Zig -> C (longjmp)
<andrewrk>
yes, but why would you do that?
<daurnimator>
andrewrk: e.g. writing a postgres extension, or a lua library.
<andrewrk>
sounds like a recipe for lots of annoying bugs
<daurnimator>
It's the nicest way to handle errors I've ever seen for C :P I write quite a few Lua libraries. Would be a bit of a deal breaker if I couldn't write them with Zig. See https://www.lua.org/manual/5.3/manual.html#4.6 for some info
<daurnimator>
andrewrk: I would have guessed from the presence of zig's `defer` that I would need to annotate a potentially longjmp-ing call with something?
<andrewrk>
yeah I mean if the API you're using requires it, I suppose you're stuck using it
<andrewrk>
you expect longjmp to execute defers if it gets triggered in C code?
<andrewrk>
defer just makes the expression get evaluated on scope exit. long jump side-steps scope exit, so it skips defers
<andrewrk>
you can't use defer if longjmp is going to cause control flow to exit scope
<daurnimator>
andrewrk: that was my thought! hence the original question: "does it (zig) rely on unwinding?"
<daurnimator>
is the answer "only in the presense of 'defer'"?
<daurnimator>
does any other syntax/etc rely on it? or implicitly use defer?
<andrewrk>
no zig does not rely on unwinding. defer just generates the expression on scope exit
<daurnimator>
andrewrk: I'd sort of expect some sort of function annotation to say "this function may longjmp". and then the compiler would warn if that flag it not propagated for all functions in the stack. and it would warn/error if you used 'defer' inside of one of those functions
<andrewrk>
that sounds like a reasonable annotation to add
<daurnimator>
andrewrk: uh, to me 'scope exit' *is* unwinding? to a degree.
return0xe has joined #zig
return0e has quit [Ping timeout: 244 seconds]
_whitelogger has joined #zig
<andrewrk>
daurnimator, what's the issue?
<andrewrk>
the annotation feature?
<daurnimator>
andrewrk: feature request for may-longjmp annotation
<joebobjoe>
"(Of course, even in Zig foo() could deadlock and prevent bar() from being called, but that can happen in any Turing-complete language.)" <- doesn't the language have to support parallelism to deadlock?
<joebobjoe>
how can **any** turing complete language deadlock?
joebobjoe has quit [Client Quit]
joebobjoe has joined #zig
<andrewrk>
joebobjoe, while (true) {}
reductum has joined #zig
reductum has quit [Client Quit]
<joebobjoe>
andrewrk, oh, I thought deadlock meant contention of shared resources
<geemili>
New here, is there a stdlib function that compares the contents of two ArrayLists?
<geemili>
Or, is there a way to compare two structs with `==`?
davr0s has joined #zig
dbandstra has joined #zig
joebobjoe has quit [Read error: Connection reset by peer]
return0xe has quit [Remote host closed the connection]
return0xe has joined #zig
wink_ has joined #zig
geemili has quit [Quit: Page closed]
wilsonk has quit [Read error: Connection reset by peer]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
dbandstra has quit [Quit: Leaving]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
wilsonk has joined #zig
tdc has joined #zig
davr0s has joined #zig
porky11 has joined #zig
return0xe has quit [Read error: Connection reset by peer]
return0e has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
Hejsil has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Hejsil has quit [Quit: Page closed]
davr0s has joined #zig
_whitelogger has joined #zig
daurnimator has joined #zig
halosghost has joined #zig
<halosghost>
is there any plan for zig to offer saturation-on-overflow rather than {w,t}rap-on-overflow?
<andrewrk>
only in the std lib
<halosghost>
mm
<halosghost>
and, presumably, promotion-on-overflow is not planned?
<andrewrk>
how does that work?
<halosghost>
for example, if the result of adding two 32 bit integers would overflow 32 bits, both are promoted to 64 bits and then the calculation is completed, returning the correct answer
<halosghost>
noting that different operators would require different widths to guarantee the proper result being possible
<halosghost>
and that with arbitrarily-sized, fixed-width integers, keeping yourself bound to powers-of-two is not necessary
<andrewrk>
that will probably be in the std lib too
<halosghost>
interesting
<andrewrk>
you don't need to promote all the way to 64 bits for addition
<andrewrk>
only 1 bit
<halosghost>
andrewrk: that's true
<andrewrk>
u32 + u32 can be safely stored in a u33
<halosghost>
andrewrk: except in the worst case, promoting only 1 bit could allow for another promotion being needed on the next addition
<andrewrk>
which can implicitly cast to a u64
<halosghost>
true
<andrewrk>
there's no difference to the processor, just to the optimizer / type safety
<halosghost>
I guess what I'm getting at is that, if other overflow-resolution strategies are implemented, having separate operators for each strategy is going to become frustrating
<halosghost>
knowing zig, I might suggest an @function that can set the overflow strategy
<halosghost>
(per-scope)
<andrewrk>
I don't think you're describing a realistic problem
<andrewrk>
let's talk about it when you're actually hitting this problem in a project
<halosghost>
hehe
<halosghost>
fair enough
<halosghost>
can you point me to how to do saturating arithmetic in the std lib?
<andrewrk>
I don't think we have any implementations currently. it's a short & fun exercise to write the functions yourself
<halosghost>
ahh, I see
<halosghost>
fernuff
<halosghost>
(having flexible, per-scope overflow strategies has been something I've wanted in C for a long time; sorry if it came across as bikeshedding)
allochi has joined #zig
allochi has quit [Ping timeout: 256 seconds]
darithorn has joined #zig
<jfondren>
what type would a+b have, when a and b are i32 and + allows promotion on overflow?
<halosghost>
iirc, overflow on addition can safely be represented in a one-bit wider type
<halosghost>
so, i33
<jfondren>
so every single addition with overflow will add a bit to the type?
<halosghost>
oh
<halosghost>
I see what you mean
<halosghost>
mm
<halosghost>
not clear
<halosghost>
it might not have to
<halosghost>
it might be able to only return the promoted type when overflow actually occurs
<halosghost>
which would, of course, be the preference
<jfondren>
so i32!i33
<halosghost>
I suppose
<andrewrk>
you can't do `x += 1` if you want promotion on overflow
<jfondren>
I imagine you'd do some math, end up with an i32!i33!i34!i35!i36 , and then pause to handle any overflow, and continue on with a single type
<andrewrk>
jfondren, what is this syntax?
<andrewrk>
I'm considering renaming comptime_int to be just `int` and allowing it to have runtime values in this way
<jfondren>
I'm thinking of the error!i32 syntax.
<andrewrk>
but i32 is not an error
<halosghost>
similarly, overflow on multiplication can be safely represented in bits * 2
<andrewrk>
anyway the compiler would keep track of the min/max values of each int. and then you could implicitly cast the int to a fixed width int if it fits. or you might have to use @intCast, or std.math.cast
<halosghost>
so, i32* would return an i32 or an i64 on overflow
<andrewrk>
it can't have a different type depending on the runtime value of the multiplication
<andrewrk>
types are all comptime known
<halosghost>
mmm
<halosghost>
fair enough
<halosghost>
in that case, it would have to promote ahead of time
<halosghost>
which is less than ideal
<halosghost>
incidentally, part of this idea comes from the Mill processor
<halosghost>
which supports promotion-on-overflow arithmetic instructions
Ichorio has joined #zig
Hejsil has joined #zig
m4ge123 has joined #zig
<andrewrk>
Hejsil, nice work
<Hejsil>
Now I'm thinking about the best course of action for tuples
<andrewrk>
I'm stuck in my implementation of #1652 :(
<andrewrk>
not happy with the code so far, I think I have to start over
<andrewrk>
I hate it when your yak won't sit still while you try to shave it
<halosghost>
lol
<andrewrk>
Hejsil, my suggestion would be to add tuples first, get tests passing, and only then try to remove var args
<Hejsil>
Agree, that seems like a good idea
<andrewrk>
tuples relate to my work in #1652
<andrewrk>
it will make tuple initialization and parameter passing never require a memcpy
<halosghost>
ooh
<Hejsil>
Right now, tuples + anonymouse initializers (#683 and #685) seems like the way to go, but Im still not 100% on it yet
<andrewrk>
and if we have syntax such as: `var a, var b = tuple_init_syntax` it will never even construct a tuple; it would just directly initialize a and b even though it used a tuple
<Hejsil>
Right now, I'm woundering how @inlineCall and the likes will work with tuples
<andrewrk>
also with #1652 once it's done, and we have anonymous initializers, we will probably remove non-anonymous initialization syntax
<andrewrk>
@inlineCall will accept exactly 2 args. the function reference, and a tuple of args
<andrewrk>
also introduce @call which is a normal call that takes the same 2 args
<Hejsil>
But what about `fn a(comptime b: type) void`
<Hejsil>
You can't have comptime values in structs that are runtime known
<andrewrk>
I see what you are thinking about
<andrewrk>
a tuple literal can have mixed comptime/ non comptime values
<Hejsil>
Hmm. Well i guess that could make sense
<Hejsil>
I was also woundering if something like `fn a(b: u8, c: []const u8) void ... a(.{.b = 2, .c = ""});`
<andrewrk>
it's not clear in my mind yet how exactly to do this either
<Hejsil>
would be interesting
<Hejsil>
Aka, an anonymus struct literal could be passed as agrument to a function, if the names and types match
<andrewrk>
yes this anonymous struct literal is related to tuples
<andrewrk>
ah I see
<andrewrk>
I like the idea
<Hejsil>
I wonna discuss this with the peoples of Zig, but idk if I should make a new issue (anonymous literals) that covers everything, or post on (#683 and #685)
<andrewrk>
up to you
<andrewrk>
eventually we'll get something nailed down and close all the issues
<andrewrk>
I really need to get this copy elision branch done... but my code is such garbage right now, I need to re think it
<Hejsil>
Alright, I'll think about it a little more and then put out my thoughts. I'm off for now
<andrewrk>
later
<Hejsil>
And gl with the copy elision
Hejsil has quit [Quit: Page closed]
<bheads>
h man, big features comming! Loving it all
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
Jenz has joined #zig
Jenz has quit [Remote host closed the connection]
halosghost has left #zig ["WeeChat 2.2"]
Jenz has joined #zig
Jenz has quit [Quit: leaving]
return0xe has quit [Read error: Connection reset by peer]
porky11 has quit [Quit: Leaving]
return0e has joined #zig
Ichorio has quit [Ping timeout: 272 seconds]
tom1998 has joined #zig
<tom1998>
Hey!
<tom1998>
Any way to deal with arrays of types?
<andrewrk>
tom1998, yes, you can deal with them in comptime code
<tom1998>
Is there any way to store multiple pointers to different types in the same array?
<tom1998>
Currently I have a [][*]u8, and i'm trying to loop through and ptrCast, but can't because it says I'm using a runtime value
<andrewrk>
did you `inline` the loop so that the loop values can be comptime?
<andrewrk>
or put the whole thing inside a comptime block
<tom1998>
ahhhhh hang on
<tom1998>
let me try that!
<tom1998>
Also, are there any plans to be able to declare structs with fields named by const strings?
<tom1998>
'cause this can be combined with stuff like @memberName to produce code that you just can't produce in other typesystems, which would be really cool
<andrewrk>
you could accomplish this already using @field
<andrewrk>
oh you're trying to construct a type, not initialize a struct