<ed_t>
wierd that I cannot do: while (i) but must include the |c| which ends up creating a const I just use once...
<ed_t>
unless i use while (i == null)
<ed_t>
that should be not equals
cole-h has joined #zig
ColonelPhantom has quit [Quit: Vision[0.10.3]: i've been blurred!]
gonz_ has quit [Read error: Connection reset by peer]
gonz_ has joined #zig
mmohammadi9812 has quit [Ping timeout: 260 seconds]
mmohammadi9812 has joined #zig
mmohammadi9812 has quit [Ping timeout: 264 seconds]
frett27_ has joined #zig
Stephanie has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #zig
craigo_ has joined #zig
blueberrypie has quit [Remote host closed the connection]
dch has quit [Ping timeout: 260 seconds]
betawaffle has quit [Ping timeout: 260 seconds]
blueberrypie has joined #zig
betawaffle has joined #zig
xackus has joined #zig
dch has joined #zig
craigo has quit [Ping timeout: 260 seconds]
wootehfoot has joined #zig
mmohammadi9812 has joined #zig
xackus has quit [Ping timeout: 258 seconds]
xackus has joined #zig
seadragon-droid has quit [Quit: Ping timeout (120 seconds)]
cole-h has quit [Ping timeout: 240 seconds]
a_chou has joined #zig
seadragon-droid has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
seadragon-droid has quit [Quit: Connection closed]
xackus has quit [Ping timeout: 265 seconds]
xackus has joined #zig
travv0 has left #zig [#zig]
leon-p has quit [Ping timeout: 240 seconds]
leon-p has joined #zig
Patrice_ has joined #zig
frett27_ has quit [Ping timeout: 272 seconds]
gazler_ has joined #zig
gazler has quit [Ping timeout: 240 seconds]
riba has joined #zig
a_chou has quit [Quit: a_chou]
shurane has quit [Read error: Connection reset by peer]
shurane has joined #zig
jokoon has joined #zig
kchambers has joined #zig
frett27_ has joined #zig
Patrice_ has quit [Ping timeout: 272 seconds]
xackus has quit [Ping timeout: 265 seconds]
amk has joined #zig
dom96 has joined #zig
dom96 has quit [Changing host]
marijnfs has quit [Quit: WeeChat 2.8]
xackus has joined #zig
jukan has quit [Ping timeout: 264 seconds]
<ed_t>
zig's expressions have some wierd limits,
<ed_t>
for instance var x:32 and later x/2 fails and you have to do @divTrunc making the code harder to read
<ed_t>
and divide throws way some info...
<ed_t>
thats x:i32
<ed_t>
or with var x:u32 and later i<<(x+x) fails
<ikskuh>
ed_t: what's the correct way for integer division?
<ikskuh>
it's clear for unsigned ints, but it's not clear for signed division
<ed_t>
in 40+ years of coding I have never seen a problem dividing signed ints
<ikskuh>
happy you :D
<ed_t>
using many many langs
<ikskuh>
what mode did they use? trunc, floor or ceiling? ;)
<ed_t>
you just need to understand what you are doing (2complement, 1complement) drop the bits. If i want rounding up or down I will take care of it...
jokoon has quit [Quit: Leaving]
<ed_t>
try coding on a cad program in forth using 64 bit int doing intergrated circuit design...
earnestly has quit [Quit: WeeChat 3.1-dev]
hnOsmium0001 has joined #zig
zags has joined #zig
<zags>
Docs says @as "is the preferred way to convert between types, whenever possible.
<zags>
so should I use that instead of @intCast for casting between integer types too?
<dutchie>
if you can use @as you should, but it won't work for potentially-lossy integer casts
<dutchie>
i.e. shrinking widths or going from signed -> unsigned
<dutchie>
then you have to LBYL and use @intCast
<zags>
this is only about converting integer and float literals to specific types
<dutchie>
then @as should always work (or fail at compile time)
<zags>
cool, i'm writing a bunch of U32, U64, etc wrappers as I have a ton of literals of various sizes and I'm not doing the verbose cast on all of them :d
<zags>
^ pretty much a bunch of those so I can write U64(5) :D
<zags>
which makes fmt complain because it's not camelCase, and proper case clashes with the type :D
<zags>
s/fmt/zls
<zags>
interesting that 3.0 converts to comptime_int, but not 3.x, seems inconsistent even if it's safe
<Gliptic>
is there any suggestion to add explicitly typed integer literals, because I find @as clunky
reductum has joined #zig
<zags>
i'll push up a lib with those wrappers if peeps wanna use them until (if) std gets them
<andrewrk>
Gliptic, I recognize that @as feels clunky but it's not supposed to
<zags>
sometimes there's lots of literals :D
frett27_ has quit [Ping timeout: 272 seconds]
<andrewrk>
it's pretty rare to need a typed integer literal
<andrewrk>
for initializing a struct or array, or a function call, the int literal will be automatically coerced
<andrewrk>
and var decls can be annotated with types
<Gliptic>
fair enough, I do appreciate that there's a "cast" that doesn't destroy information, most languages don't even have it
<Gliptic>
I find that a major shortcoming in Rust, which is very strict about e.g. array indexes being usize, but "as" casts is the only way to convert
<zags>
my use case that I've bit fiddling code that shifts and masks, so I'm using the wrappers to make that readable
<zags>
andrewrk: good point, I'm just converting C++ code so step 1 is making it work. That looks interesting, thanks!
<zags>
a potentially stupid idea: a lot of structs will have open/close, allocate/free, etc pairs. Would it make sense to allow tagging those as opening and closing resources? It would be optional and have no effect other than enabling potentially powerful static analysis. If you called open but don't call close, something fishy is going on.
Akuli has quit [Quit: Leaving]
<zags>
could take scopes and escape analysis into account I suppose
<andrewrk>
ifreund, check it out, the capacityInBytes function for MultiArrayList, written cleanly using SIMD: https://clbin.com/yNMnH
<andrewrk>
arguably it's cleaner than the non SIMD version. here are both side by side for comparison: https://clbin.com/OsZui
<zags>
andrewrk: do you think static analysis will ever be powerful enough to catch our forgot-defer mistakes, or is that an open problem/not solvable/nonhalting/etc ?
<andrewrk>
not solvable because it may be intentional
<Gliptic>
arena allocators etc.
<zags>
yeah, it would need some sort of demarkation I guess