Migrate to Zig 0.15.2

[pmarreck]

Summary

This migrates the entire codebase from Zig 0.14.1 to Zig 0.15.2. No new features or behavioral changes — this is purely a language/API migration.

This is the first of several focused PRs that replace the monolithic #121 (which the maintainer correctly identified as too large to review).

Key API changes

• usingnamespace removal — replaced with explicit re-exports for every mixin declaration throughout components, backends, and examples
• ArrayList API — .init(allocator) → .empty + pass allocator to each method call
• Calling conventions — callconv(.C) → callconv(.c) (lowercase enum literals)
• Win32 API — std.os.windows.WINAPI → std.builtin.CallingConvention.winapi
• String formatting — std.fmt.allocPrintZ → std.fmt.allocPrintSentinel
• Atomics — std.atomic.Atomic → std.atomic.Value
• Sorting — std.sort.sort → std.mem.sort
• Sleep — std.time.sleep → std.Thread.sleep
• Data structures — SinglyLinkedList became intrusive (compat wrapper added), BoundedArray removed (replacement added)
• Async — anyframe removed (async.zig stubbed since the async subsystem was already incomplete)
• URI — std.Uri.path.toRaw signature changed
• zigimg — StreamSource → ReadStream API
• vendor/zigwin32 — mechanical migration of all 293 files for 0.15.2 compatibility
• build.zig / build_capy.zig — updated for 0.15.2 build API changes
• build.zig.zon — updated dependency hashes for zig-objc and zigimg
• flake.nix — updated to Zig 0.15.2 toolchain

Test plan

• All 28 examples compile on x86_64-windows-gnu (cross-compile)
• Native macOS build compiles and runs
• GTK/Linux build (needs Linux environment with GTK4 dev packages)
• WASM build
• Android build

[pmarreck]

I'm newish to Zig, and I'm finding that Zig upgrade PR's are beasts. (Ghostty apparently had a ton of required updates, too.)

It's possible that you might not want to go through this pain again for 0.16 and will want to wait for that (likely this year) to drop.

If you want, we can just leave this open as the "comprehensive upgrade PR" and just update it for 0.16 when that's appropriate.

[zenith391]

A more general thing is that the vendor/zigwin32 comes from https://github.com/marlersoft/zigwin32 which has been independently updated for zig 0.15.0, so instead of letting an AI agent update those files, the best course of action would have been to just take the upstream repository.
Besides, I vendored zigwin32 back when the Zig package system wasn't ready (and the library had a few bugs I fixed manually), but now this serves a purpose that no longer exists. So something even better would be to use build.zig.zon instead.

[pmarreck]

ah, makes sense, then you get the upstream whenever you update. will rejigger it

[TeeEnnEnn]

@zenith391 and @pmarreck Zig 0.16 has been released. Is the intention still to make one migration to 0.16?

If so, can this be picked up?

[pmarreck]

I've upgraded all of my personal Zig projects to 0.16 but regarding Capy specifically, I've chosen a different solution for now on my cross-platform projects (GPUI with gpui-component, same things the Zed editor uses, and even though it is Rust, I came up with a way for it to call into my Zig core code that works great) so I have personally lost motivation in pursuing Capy dev anymore for now since it still needs a lot of work and GPUI works great

[pmarreck]

Also, just an opinion here, it would've been absolutely infeasible for me time-wise to upgrade all of my Zig projects to 0.16 without AI assistance, so there's that. I know the Zig community has… thoughts… on frontier LLM use, but for really boring/mechanical things like making CI pass or... upgrading dependencies to newer versions and then fixing all the new fails... it is absolutely superb

[kchilton]

This is why I stopped chasing Zig upgrades. I will wait for the flailing to stop before investing more time in it. Stopping at 0.15.2 and then waiting for something Capy needs from a Zig update before making the next upgrade will be less work overall.  The same technique held true in the whole industry for upgrades to the C standards. Not many are jumping to C23. There just are not any compelling benefits to justify dropping C11 feature and syntax (and therefore C17) compatibility and breaking the longstanding backward compatibility and refactoring stable code for no returns. Much more code is still generated in C99 and C11/C17 than C23. So far, the draft for C29 looks interesting since it is absorbing some Rust and Zig innovations, such as defer, so migrating standards every 18 years might be the new pattern. On Aug 2, 2026, at 7:53 AM, Peter Marreck ***@***.***> wrote:pmarreck left a comment (capy-ui/capy#122) Also, just an opinion here, it would've been absolutely infeasible for me time-wise to upgrade all of my Zig projects to 0.16 without AI assistance, so there's that. I know the Zig community has… thoughts… on frontier LLM use, but for really boring/mechanical things like making CI pass or... upgrading dependencies to newer versions and then fixing all the new fails... it is absolutely superb —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[pmarreck]

Yep, I hear that.

And I was planning on doing the same (basically waiting on, say, a 0.16.1 point release) but as it turned out, a lot of the Zig deps I needed all went to 0.16 and not doing so suddenly became a liability for a pre-product launch so I decided to have the LLM write an upgrade guide https://gist.github.com/pmarreck/5424b5ecb0744f2c9641b83c4043afb8 and handed that to an agent’s context that was assigned to upgrade a project, and that worked out great.

[TeeEnnEnn]

@pmarreck can I pick up from this branch and migrate capy to 0.16?

[pmarreck]

@TeeEnnEnn Of course!