ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
donniewest1 has quit [Ping timeout: 276 seconds]
rowbee has quit [Remote host closed the connection]
rowbee has joined #zig
ur5us__ has joined #zig
washbear has joined #zig
racoon has quit [Quit: ZNC 1.8.1 -]
Ziemas has quit [Ping timeout: 246 seconds]
donniewest1 has joined #zig
donniewest1 has quit [Ping timeout: 258 seconds]
brzg has joined #zig
earnestly has quit [Ping timeout: 256 seconds]
mikdusan1 has joined #zig
squeek502_ has joined #zig
squeek502 has quit [Remote host closed the connection]
Snetry has quit [Quit: left Freenode]
mikdusan has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
donniewest1 has joined #zig
gazler_ has joined #zig
evbo has quit [Ping timeout: 246 seconds]
donniewest1 has quit [Ping timeout: 276 seconds]
ur5us__ has quit [Ping timeout: 264 seconds]
gazler__ has quit [Read error: Connection reset by peer]
ur5us has joined #zig
brzg has quit [Quit: leaving]
marijnfs has quit [Quit: WeeChat 2.8]
Amun_Ra has quit [Ping timeout: 246 seconds]
Amun_Ra has joined #zig
a_chou has joined #zig
jjido has quit [Quit: Connection closed for inactivity]
jukan has joined #zig
osa1 has quit [Ping timeout: 272 seconds]
jukan_ has quit [Ping timeout: 264 seconds]
hspak has quit [Quit: bye]
hspak has joined #zig
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 246 seconds]
xackus has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
<andrewrk> haha
ur5us_ has quit [Ping timeout: 264 seconds]
a_chou has quit [Remote host closed the connection]
Xatenev has joined #zig
terinjokes has quit [Quit: ZNC 1.8.1 -]
terinjokes has joined #zig
_whitelogger has joined #zig
terinjokes has quit [Quit: ZNC 1.8.1 -]
Xatenev has quit [Quit: Leaving]
terinjokes has joined #zig
terinjokes has quit [Client Quit]
terinjokes has joined #zig
mmohammadi9812 has quit [Read error: Connection reset by peer]
mmohammadi9812 has joined #zig
mmohammadi9812 has quit [Ping timeout: 240 seconds]
mmohammadi9812 has joined #zig
midgard has quit [Ping timeout: 272 seconds]
g-w1 has quit [Ping timeout: 264 seconds]
g-w1 has joined #zig
frett27_ has joined #zig
midgard has joined #zig
mk12 has joined #zig
frett27_ has quit [Ping timeout: 258 seconds]
<mk12> I'm trying to make a cross-platform game with Zig. It's really cool being able to use C libraries seamlessly, and build them in build.zig. But the libraries I'm using (glfw, bgfx) use some Objective-C in their macOS builds. Is there any reason why build.addCSourceFile couldn't also support Objective-C? In the end it's just passing it off to clang,
<mk12> right?
osa1 has joined #zig
frett27_ has joined #zig
sord937 has joined #zig
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
frett27_ has quit [Ping timeout: 272 seconds]
mk12 has quit [Quit: Connection closed]
decentpenguin has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has joined #zig
mmohammadi9812 has quit [Ping timeout: 240 seconds]
mmohammadi9812 has joined #zig
tsujp1 has quit [Ping timeout: 260 seconds]
jukan has quit [Ping timeout: 240 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
mmohammadi9812 has quit [Quit: Quit]
Xatenev has joined #zig
gazler_ has quit [Ping timeout: 258 seconds]
<motiejus> Andrewrk mentioned yesterday: zig bundles (links in) the cc and c++ compilers, so in order for it to work the same way, it would need to bundle objc compiler and supporting libs too (maybe it does, but I doubt); also see
gazler has joined #zig
Xatenev has left #zig ["Leaving"]
gazler has quit [Quit: Leaving]
<terinjokes> maybe zig can do better, but I've found getting the objective-c headers needed to cross-compile (and then getting a working toolchain) to be very annoying.
kbd_ has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
jukan has joined #zig
jukan has quit [Ping timeout: 256 seconds]
gazler has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
earnestly has joined #zig
drawkula has joined #zig
yeti has quit [Ping timeout: 246 seconds]
drawkula is now known as yeti
cole-h has quit [Ping timeout: 240 seconds]
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
koakuma has joined #zig
wilsonk_ has joined #zig
<koakuma> Hi, I need some help with @frameSize
<koakuma> And @frameSize simply loads it from that place. Am I correct?
<koakuma> AFAICT each Zig function has its frame size stored in an usize-sized block just before its entrypoint
koakuma has quit [Read error: Connection timed out]
koakuma has joined #zig
<koakuma> So on sparc64 @frameSize(func) compiles to something like `ldx [&func-8], %someregister`
<koakuma> ldx needs the address to be aligned to 8 bytes, but functions only need to be aligned to 4 bytes
<koakuma> So if I'm being unlucky, that ldx instruction might crash my program because of unaligned access
<koakuma> Is it possible to make @frameSize generate something that is more suitable for unaligned addresses?
<wilsonk_> koakuma, can you just do an actual @setAlignStack right before the call?
decentpenguin has quit [Ping timeout: 264 seconds]
<wilsonk_> I am not sure though, as I haven't used that builtin before...kindof early here in NA still, but maybe someone else with more experience with @setAlignStack will be online soon
<koakuma> wilsonk_: Still doesn't work - it doesn't seem to make any difference to the alignment of the function code itself
decentpenguin has joined #zig
<wilsonk_> hmm, I seem to remember there was a way to do that though...sorry I can't remember it off hand.
M-ou-se has quit [Ping timeout: 256 seconds]
M-ou-se has joined #zig
<ifreund> hmm, std.Target.stack_align is 16 for all targets afaict
bitmapper has joined #zig
<koakuma> I believe that this is probably a codegen bug - @frameSize should generate an instruction (or sequence) that can handle unaligned addresses
<ifreund> Yeah certainly
<ifreund> wonder if it's zig's fault or llvm's fault
techtirade has quit [Read error: Connection reset by peer]
techtirade has joined #zig
<koakuma> Where does @frameSize get implemented? I wanna try taking a peek there
<ifreund> koakuma: probably grep for "frame_size" in src/stage1/ir.cpp
<koakuma> gen_frame_size in codegen.cpp?
<koakuma> Ah okay
<ifreund> the codegen part would be in codegen yeah
<koakuma> Seems like it's Zig's fault?
<koakuma> It generates a `load align 8` in LLVM IR when it should be `align 1`, I think?
<ifreund> I don't have enough knowledge to know if that's right or not. I'd recommend opening an issue so the people that do don't miss it
<koakuma> Yeah
sord937 has quit [Remote host closed the connection]
jukan has joined #zig
sord937 has joined #zig
jukan has quit [Ping timeout: 246 seconds]
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
matt444 has joined #zig
matt444 has quit [Quit: Ping timeout (120 seconds)]
notzmv has quit [Remote host closed the connection]
zags has joined #zig
<zags> hey, what's the idiom for converting a u64 to a slice of bytes, so I can pass it to a function expecting []const u8 ?
<ifreund> zags: pretty sure there's std.mem.valueAsBytes() or similar
<ifreund> just std.mem.asBytes acutally
<zags> .asBytes looks like the one
<zags> right, thanks
<ifreund> no problem!
<zags> ifreund: and the other way around? :D
<zags> bytesAsValue maybe
<ifreund> zags: asBytes
<ifreund> er, no
<ifreund> bytesAsValue is right
<zags> good stuff
<ifreund> there's also bytesToValue() for some reason if you want to save typing a .*
donniewest1 has joined #zig
tnorth has joined #zig
<tnorth> Hi there. I'm confused about zig cc cross compilation: zig cc foo.c --target=powerpc-linux-gnu (listed in zig targets under "libc") gives: "error: unknown target CPU 'ppc32'" + a list of valid targets. How do I specify that exactly?
frett27_ has joined #zig
kbd has joined #zig
nycex has quit [Ping timeout: 268 seconds]
nycex has joined #zig
ifreund1 has joined #zig
ifreund has quit [Ping timeout: 258 seconds]
<tnorth> Hmm, do I correctly understand that cross-compiling with zig cc to powerpc targets is not supported yet, because belongs to Tier-3 ?
hristo has quit [Quit: hristo]
<wilsonk_> tnorth, powerpc64 works and it is only Tier 3/4 so I don't think that is it
<wilsonk_> powerpc64le also works for a simple example
<fengb> Maybe ppc32 doesn't work
<mikdusan1> it might be a mapping issue
waleee-cl has joined #zig
jukan has joined #zig
<wilsonk_> hmmm, arm-linux-musleabi works but arm-linux-gnu doesn't (can't find stdio.h) even though that exact triple is an example on the release-notes page for 0.6
<mikdusan1> `zig build-obj` seems ok with the target. but `zig cc` not; so the clang driver is emitting the diag about ppc32
<wilsonk_> oh, weird
<mikdusan1> s/clang driver/zig cc driver/
<wilsonk_> with arm-linux-gnu it ends up in an infinite loop here after outputting the error
<wilsonk_> that is using master
<mikdusan1> zig cc or build-obj ?
<wilsonk_> infinite loop with zig cc
<mikdusan1> `zig cc -c foo.c -target arm-linux-gnu` gives me a few warnings but no error or loop
<mikdusan1> master.
<wilsonk_> yikes...I literally just built it 10 mins ago. Let me clean up and try again
<wilsonk_> oh, yeah I don't have musl installed universally so I have to use -I to specify the zig fine then
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<wilsonk_> I haven't tried cross compiling anything in a while :)
kbd has joined #zig
<mikdusan1> still, an inf loop because no header/-I flag is still a bug
hnOsmium0001 has joined #zig
a_chou has joined #zig
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
<mikdusan1> I don't have 100% confidence in this but a 1-liner patch seems to fix the mapping issue:
wilsonk_ has quit [Ping timeout: 240 seconds]
<tnorth> mikdusan1: thank, I'll try that then...
<tnorth> mikdusan1: how do you run it though?
<tnorth> (I keep having the same message)
zags has quit [Ping timeout: 258 seconds]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<mikdusan1> `zig cc -c foo.c -target powerpc-linux-gnu` and w/ patch this should get you further to a .h error
<mikdusan1> `zig cc -c foo.c -target powerpc-freestanding` is even more minimal
<tnorth> error: unknown target CPU 'ppc32' but no .h errors then
<mikdusan1> you need to rebuild zig with the patch
<tnorth> yep, let me check if I manage that...
<tnorth> would this produce a proper PPC32 executable then?
<mikdusan1> not likely
<mikdusan1> well i stand corrected. glibc wasn't happy. but musl is:
<mikdusan1> `zig cc -o foo foo.c -target powerpc-linux-musl`
<mikdusan1> "foo: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped"
<tnorth> Ok, I had the impression that zig could already compile for all arch listed in the support table, but in fact it currently can compile for x86_64, arm64, arm32, mips32 LE, i386, and riscv64 "only"
<tnorth> ah nice
<tnorth> will you then submit your patch?
<mikdusan1> if you can open an issue, I'll follow up with a PR on it. but even though it's a 1 liner, andrew is real busy right now on stage2 work. so it might be a while before review.
<marler8997> I found a bug in generic function instantiation where the compiler doesn't see 2 comptime strings as equivalent if one of them is a slice, even if their contents are the same,anyone know if this is a known bug?
<fengb> In theory Zig has better support without libc
<mikdusan1> marler8997: is one null terminated and the other not?
ifreund1 is now known as ifreund
<marler8997> no
<tnorth> mikdusan1: Thanks, I understand. Issue is at
<mikdusan1> 👍
<marler8997> mikdusan1, I've opened an issue here if you're interested:
Akuli has joined #zig
Patrice_ has joined #zig
frett27_ has quit [Ping timeout: 272 seconds]
zags has joined #zig
<zags> rust has wrapping_neg, modular negation. Do I simply do `0 -% num` in Zig?
<g-w1> yes
<zags> thanks
<ifreund> zags: I don't think you need the 0
<ifreund> -% is a unary operator as well
<ifreund> marler8997: pretty sure I've hit that before, but I don't remember a bug report
<marler8997> ifreund ok thanks
<mikdusan1> why does github butcher linefeeds so much when a horiz scroll bar is added to code block :(
kbd has joined #zig
kbd has quit [Client Quit]
zags has quit [Quit: leaving]
kbd has joined #zig
zags has joined #zig
<zags> I have a task that I want all cpu cores to compete working on, and I need to return the result as soon as a thread has found the answer. I was initially thinking a thread pool, but maybe cpuCount() number of async calls with .evented would do the same job?
<zags> Then somehow await until one of the frames return
<ugla> you would still need something for paralellism
<zags> doesn't .evented fire up a thread per core?
cole-h has joined #zig
tnorth has quit [Ping timeout: 260 seconds]
<andrewrk> by default evented fires up a thread per core but it will only start utilizing extra threads if (1) you use an async fn call and (2) the async function call blocks on I/O
<zags> i see, i'll do a thread pool for now then. 5263 looks v interesting
<andrewrk> however you can use std.event.Loop.startCpuBoundOperation() to introduce a point where control flow takes advantage of the thread pool
<zags> ohhh
<zags> perfect
<andrewrk> I recommend to only use this sparingly, when you notice that cores are not being properly utilized
<zags> right, in my case i need to utilize all cores to get the result asap
<zags> the async function will loop until it finds the solution, the other calls in flight should then terminate (same function being called N times, once per core)
<zags> guess I can communicate that with a volatile, or an atomic flag (if the std has that)
<marler8997> andrewrk, looks like I tracked down the issue I was having with if you want to take a look at it
<andrewrk> roger that
<philtor> wondering if there is any binary tree example code in zig that highlights zig language features? Googling for this is pretty much no possible. (you get Binary Tree ZigZag traversal stuff)
kevsmith has joined #zig
frett27_ has joined #zig
Patrice_ has quit [Ping timeout: 272 seconds]
<justin_smith> philtor: stdlib has sets and hash-maps and I'd be surprised not to find trees in the source...
<ifreund> no trees in the std HashMap
<ifreund> std used to have a rb tree but that was orphaned
<mikdusan1> was just looking for it. what does oprhaned mean? not maintained?
<mikdusan1> ah thanks
<mikdusan1> James Bond was an orphan. true fact.
jukan_ has joined #zig
jukan has quit [Ping timeout: 272 seconds]
<ifreund> marler8997: I don't think memoization can/should work for dynamic strings built at runtime, did you mean comptime?
<marler8997> yes comptime
<marler8997> thx for correction
<ifreund> no problem, I think this issue definitely needs attention
<ifreund> I forgot that I stopped working on that branch because of it
LanceThePants has quit [Read error: Connection reset by peer]
<marler8997> interesting that the strings that match still have the same pointer, it looks Zig has already anticipated these issues
<ifreund> mine don't seem too, or something else is causing it to fail
<ifreund> I suppose what you're seeing is just llvm optimizing stuff tbh
<ifreund> by the way if you feel like gawking at the stage1 code, grep for "memoized_fn_eval_table"
<marler8997> could be, that would explain why Zig thinks they are different but LLVM may have optimized them to be the same
sawzall has joined #zig
frett27_ has quit [Ping timeout: 272 seconds]
<zags> is there a workaround while waiting for the select in #5263 ? Basic need is fireing off a bunch of async calls, then just pick up the first one with a result
<zags> I guess I could just wait on a random one and communicate the result through an atomic, or is leaving async calls hanging without awaiting not allowed (for the remaining calls) ?
<ikskuh> you have to keep them alive until return
<ikskuh> otherwise the event loop might resume a non-existend frame
ur5us_ has joined #zig
<andrewrk> zags, there's no good alternative right now, it's a big sore spot
<zags> I see
<andrewrk> cancellation is also an unsolved problem
<zags> if it's cpu bound, can you do better than a standardized cancelation token type of thing? Something C++20 jthread-ish
<andrewrk> I think in any case, even I/O bound, it would be reasonable to make it cooperative; that is the async function would declare a cancellation point
<zags> very reasonable IMO
<andrewrk> the devil is in the details of integrating this into the language
<zags> something like @cancel(frame) and @isCanceled() inside the async function?
<zags> with an atomic flag... somewhere :)
<ikskuh> i like this version
<ikskuh> @isCancelled(@frame())
<ikskuh> or so
<zags> right
<andrewrk> it's a bit trickier than that - the cancellation has to get forwarded to calls, it's not actually per-frame
<andrewrk> consider a function that forwards its args: fn foo() void { return bar(default_value); }
<ikskuh> andrewrk: do you mean that nested frames wouldn't get cancelled?
<andrewrk> if you cancel foo in this example you also want bar to get cancelled
* zags discovers #5913
<ikskuh> can we save up-pointer for frame nesting?
<ikskuh> @parentFrame(@frame())
<ikskuh> and isCancelled can now check if the parent got cancelled as well
<andrewrk> like I said, the devil is in the details :)
<zags> always is, that fucker
<ikskuh> damn details!
<ikskuh> andrewrk: i see we support a memory model parameter in zig
<ikskuh> what effects does it have?
<andrewrk> I don't remember but I think it only has a few grep results if you want to poke around
<ikskuh> yeah :D
<andrewrk> afaik it has to do with freestanding
belgin has joined #zig
belgin has quit [Client Quit]
<ikskuh> yeah some architectures have different styles of adressing
kevsmith has quit [Ping timeout: 256 seconds]
<ikskuh> allowing more or less memory with more or less performance
a_chou has quit [Ping timeout: 240 seconds]
<zags> so I'm stuffing async frames into an std.ArrayList(@Frame(worker)), then looping to await inside for (arr.items) |item| {...}
<zags> but that gives me expected type 'anyframe->u64', found '*const @Frame(func)'
<zags> on the capture
<fengb> `for (arr.items) |*items|`
<fengb> Er... *item
<zags> what does the * do? I though .* was used to dereference
<ikskuh> in this case, it gives you a pointer to the slice element
<ikskuh> instead of a copy :)
<zags> It also gives me an ICE :)
<zags> panic: assertion failed. This is a bug in the Zig compiler.
<zags> stage1/codegen.cpp:1801
<zags> (master)
<zags> or close, 843d91e
<zags> ir_assert(instruction->value->special != ConstValSpecialRuntime, instruction);
<zags> assert(instruction->value->type);
<andrewrk> zags, ArrayList with async frames is pretty dangerous because if you resize the array it will cause unchecked UB
<zags> it's fixed to cpu count
<andrewrk> then it need not be an ArrayList, it could just be allocator.alloc(Frame, cpu_count)
<zags> alright, can try that and see if I can dodge the ICE
<zags> hm, doesn't Frame live in std.builtin?
<zags> TypeInfo I guess
<zags> ok, that worked
<zags> \o/
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<ifreund> @Frame(foo) should also work
<ifreund> that could probably be removed though now that @Type() exists...
<zags> that's what I did
<zags> this actually turned out to be a short'n'sweet thread pool, just async cpu-count times with the frames in an array, then have the workers check if anyone is done based on an atomic flag, which means awaiting in a loop works. Yay.
kbd has joined #zig
wilsonk_ has joined #zig
a_chou has joined #zig
<zags> and it runs faster than the fancy-pants Rust program I ported from, might have to break out devto and blog about it :D
sord937 has quit [Quit: sord937]
<ifreund> zags: sweet, sounds like a success :)
<zags> ifreund: indeed :) What a lovely language
<ifreund> yeah, and I'm too impatient to wait until 1.0 for stability and completeness so I'm already writing pretty much everything in Zig :D
<zags> yeah, I saw andrews tweet about not using it in production, but screw that :) Too good already.
<fgenesis> i've downgraded to C-ish C++ but wasn't able to make the jump yet even though ikskuh has been nagging me for basically forever :<
<fgenesis> (i'm sorry)
<fgenesis> and with downgraded i mean all of this high-level OO nonsense and STL and please no
Akuli has quit [Quit: Leaving]
jjido has joined #zig
ur5us_ has quit [Ping timeout: 260 seconds]
<andrewrk> C-ish C++ is what I coded in before I created zig
<zags> with Zig I rediscovered that taking away power gives you a lot of power
<ifreund> I find zig's power to simplicity ratio to be one of the most impressive things about it
<ifreund> I managed to pick up the basics well enough in a matter of days to write a hello-world wayland compositor :D
<zags> that's amazing
<ifreund> now the code definitely wasn't idiomatic at first, but it worked and grew into the compositor I've been using every day for like 6 months
<ifreund> the code's a lot better now for sure :)
<zags> only minor thing I don't like about the result is that it's a few while loops (some nested) and I have to pollute the parent scope because the while doesn't have an initializer clause, that's going to cause bugs. I understand I can wrap all the while-loops in {} to scope, but that's too ugly to contemplate in this case.
<ifreund> maybe I haven't been programming long enough, but I haven't come across a bug caused by that yet
<ifreund> I agree that it feels unclean though
<zags> well it's why C99 got declarations in for-loop
<zags> because the lack of it was causing bugs
<zags> usually when refactoring
* Gliptic has seen bugs caused by that
<Gliptic> accidental variable reuse etc.
<zags> yep
<ifreund> heh TIL C didn't have declarations in for loops until C99
<zags> it was a wonderful improvement, and zig needs it too :)
<andrewrk> I recommend to use {} to introduce variable scope, not only for while loops but in other places as well
<zags> yeah, I mentioned that above, but it gets really ugly, especially when nesting
<Gliptic> people don't do that because it becomes ugly though
<Gliptic> and extra nesting
<zags> I tried the { decl; while ... } formatting, but it doesn't help enough
<ifreund> I think zig format needs to start allowing this to get people to use blocks everywhere:
<zags> i really dislike that
<zags> it's a language weakness imo
<ifreund> I like it better than the extra nesting
<zags> yeah the formatting is the best you can do, but not a lot of people are going to do "extraneous" braces, and they'll forget when refactoring
<Gliptic> marginally better
<fgenesis> 23:25 < ifreund> I find zig's power to simplicity ratio to be one of the most impressive things about it
<fgenesis> same reason why out of all scirpting languages i like Lua the most
<fgenesis> it just comes together so nicely
<fgenesis> and it's so braindead simple
<Gliptic> (except for the 1-based indexing, *cough*)
<fgenesis> that is actually not a problem
<Gliptic> for me it is ;)
<fgenesis> it's very funny to work on a larger thing, lua and C++ at the same time, and coding the lua bindings, and do correct indexing on both sides
<fgenesis> i've learned to switch seamlessly. is really not an issue after getting into it
ur5us_ has joined #zig
<Gliptic> I've done a lot of lua <-> C/C++ bindings
<fgenesis> and by this point i actually say both indexing schemes have their right to exist
<ifreund> fgenesis: yeah I feel that, but lua is too high level for a lot of the stuff I'm interested in
<fgenesis> except, you're right, fuck 1-based indexing. for efficiency.
<fgenesis> (for great justice!)
<viashimo> does align() affect fields in a packed struct?
<Gliptic> move zig
<ifreund> viashimo: yes it should, but there may be bugs
* fgenesis hi^5 Gliptic
* ifreund wonders what happens if align() on fields of a packed struct are contradictory and hopes it's a compile error
<zags> :)
<fgenesis> zags: re "I can wrap all the while-loops in {}" -- yeah, like in VC6, where the for-variable leaked outside of the for-scope <.<
<fgenesis> easiest way to just wrap the for in double {{, like {for(...){ ... }} >.>
<Gliptic> I did that habitually, it's forever a codesmell now
<fgenesis> ohno
<viashimo> ifreund: I guess my case may be contradictory, but I'm not sure. packed struct says there will be no padding between fiels, but for the alignment to work I need the fields to be padded
<ifreund> viashimo: I'd insert padding fields manually in that case
<ifreund> also be aware that packed structs have some serious bugs in stage1:
<ifreund> I recommend comptime asserts that the alignment and size are what you expect (e.g.
<zags> fgenesis: yeah, the extra scoping will not be used (enough) and there will be bugs :( I hope this gets fixed
<ifreund> zags: I'd love to see it fixed too, I just have no idea how and nobody else has come up with a compelling proposal yet either
<zags> ifreund: while (var i = 0; i < 10) : (i += 1) {} was the natural thing that came to mind, but I understand there was an issue with using ; in Zig here
<zags> but maybe an exception for while could be used
<zags> c++17 got the same for if to help reduce scope
<zags> if (initializer; expr) {}
<ifreund> yeah, that feels pretty inconsistent to me
<zags> howso
<ifreund> currently stuff in parentheses is always a single expression
<zags> so while () : () : () {} :)
<ifreund> you have either while (i < 10) or while (blk: { more complex logic break :blk false })
<ifreund> the best suggestion I saw so far was a with keyword
<zags> how did that look?
<viashimo> ifreund: thanks for the suggestions. I'll keep investigating
<ifreund> with (var i: u32 = 0) while (i < 10) : (i += 1) { ... }
<ifreund> and you could use it other places as well to scope things
<zags> i like that, but it was rejected?
<ifreund> it hasn't been properly proposed yet, just mentioned in passing by marler8997 on a related issue
<ifreund> you should write it up if you feel strongly about it and have the time :P
<zags> i feel strongly about making it easy to not pollute scopes, yes
<ifreund> viashimo: no problem! packed structs in stage1 generally work best if nothing overlaps the byte boundries
<zags> but i don't know zig well enough to formulate a suggestion properly
<ifreund> stage2 will fix all our packed struct woes eventually
<zags> marler8997: you should write it up :)
<ifreund> +1
<zags> I still prefer the terse init; expr version, even if it feels inconsistent. Easy enough to learn
<zags> but would take with any day over current situation
<zags> with-construct*
a_chou has quit [Quit: a_chou]
donniewest1 has quit [Quit: WeeChat 3.0.1]
<marler8997> with(decls)'s an interesting idea, though, if I were a betting man I would bet against it being accepted at this point. Even if I were in Andrew's position I'm not sure I would accept it either. Zig has taken a pretty strict stance on new features, understandably so
<marler8997> mostly because today you can do { decls; expr... }
<ifreund> Yeah I'd be a little surprised to see it accepted as well tbh, but I don't think it's been properly discussed yet
<marler8997> ifreund yes, an issue just to discuss the merits may be worth it
<ifreund> I feel like it has the same problem as block do though tbh, it feels optional and people may just as easily choose not to use it
<mikdusan1> I could swear I saw an issue where someone considered (my lame terms here) auto-expanding the bits (and sign) for integers as a
<mikdusan1> way to deal with or circumvent overflow
<mikdusan1> if anyone recalls it, enlighten me with the digits please
<zags> marler8997: please do make an issue for discussion. This will be a source of bugs if not fixed.
<fgenesis> 23:51 < zags> so while () : () : () {}
<fgenesis> does this intentionally look like a forkbomb? D:
<zags> right :D
<zags> that was a joke, I really want for (;;) but that's not going to happen either afaict :)
<fgenesis> for (.) (.) (.) is one too much yeah
<zags> not if you're on Mars with Arnold
<fgenesis> i must be old that i get these references
<zags> :)
cbix has joined #zig
<ifreund> mikdusan1: this one?
<mikdusan1> no but that's why I'm trying to find the other one unless there is no other one.
v0idify has quit [Ping timeout: 268 seconds]
<mikdusan1> meh no matter
v0idify has joined #zig