This is a tracking issue for upstream Zig. (see Third Party Tracking Issues)
Overall, Zig is really great and its cross-compilation abilities are great for GUIs, but some (planned) proposals and bug fixes would make it better:
async/await (regression introduced in stage2). A lot of tasks in user interfaces are asynchronous, whether it's loading a resource or updating data on a remote server, async is important to have. Right now I'm having hacky solutions with capy.http which has an async-looking API but is actually synchronous and capy.assets which is entirely synchronous as of now, including when fetching resources over HTTP.
issue #12325 (regression introduced in stage2) is blocking me from having event handlers like fn buttonClicked(button: *capy.Button) !void instead of a more generic fn buttonClicked(button: *anyopaque) !void. Having to manually @ptrCast decreases the ease of use of the API.
The compiler crashes while trying to generate capy's documentation
(maybe) issue #1717, while it's been closed as not implemented, it would be useful in a lot of cases like Atom.dependOn instead of using the bizarre status quo of struct { fn a() void {} }.a
This is a tracking issue for upstream Zig. (see Third Party Tracking Issues) Overall, Zig is really great and its cross-compilation abilities are great for GUIs, but some (planned) proposals and bug fixes would make it better:
capy.httpwhich has an async-looking API but is actually synchronous andcapy.assetswhich is entirely synchronous as of now, including when fetching resources over HTTP.fn buttonClicked(button: *capy.Button) !voidinstead of a more genericfn buttonClicked(button: *anyopaque) !void. Having to manually@ptrCastdecreases the ease of use of the API.Atom.dependOninstead of using the bizarre status quo ofstruct { fn a() void {} }.a