For porting Zig 0.14 code to Zig 0.15: what is the correct replacement for `readByte()` on a file/reader, and where is it called from?

const a: u16 = 0;
const b: u32 = 0;
switch (a) {
     @intCast(b) => ..., // теперь работает
}

const Enum = enum(u8) { ... };

const c: Enum = ...;
switch (c) {
    @enumFromInt(0) => ..., // теперь работает
}

const Tot = enum {
    a,
    b,

    pub const c: Tot = .a; 
}

switch (...) {
    .b => ...,
    .c => ...
}

switch (...) {
    .a => |_, tag| {} // теперь можно теги ловить в обычной ветке, не только inline 
}

inline fn pageAllocator() Allocator {
    // In tests we use our testing allocator so we can detect leaks.
    if (builtin.is_test) return std.testing.allocator;

    // On non-macOS we use our standard Zig page allocator.
    if (!builtin.target.os.tag.isDarwin()) return std.heap.page_allocator;

    // On macOS we want to tag our memory so we can assign it to our
    // core terminal usage.
    const mach = @import("../os/mach.zig");
    return mach.taggedPageAllocator(.application_specific_1);
}

hey, not sure if you have heard or not but we've decided to move the next version of Tides from Zig to Jai. Our current release should happen in January I hope, or maybe if I cram it in before the end of the year (mostly a matter of how much polish I want to give it). I can still maintain zflecs, at least for a while (we'll be using flecs in the future as well and I have an interest in keeping tabs on making sure there are no weird language-spanning binding issues 🙂 )

We are still on Zig 0.14.1 though and an older version of zflecs, so I'm not able to actually update zflecs or test PRs anymore, such as this one.

https://github.com/zig-gamedev/zflecs/pull/31

We are using a number of libraries from zig-gamedev so hopefully the Tides repo will remain a useful "how do I actually use zaudio in practice" reference for a good while 🙂

and we have basically come to the realization that Zig isn't great for game development. I mean it's definitely better than C and C++ in various ways, but also not in other ways. At the start it looked like it was going to be more suited for gamedev but it has aligned more with lowlevel/systems programming. So maybe fine for lower level engine programming or libraries, but less so for the more artistic and iterative parts of game development. And now there are two C++ replacement languages that are basically designed for game development - Odin and Jai - and of those Jai speaks more to us. So long term we think it's a choice that will bring us more speed and more joy.

Prior art
This idea is taken fairly directly from zig.

Furthermore, when this work is combined with the recent std.Io changes, there is potential for users to seamlessly control how libc performs I/O - for example forcing all calls to read and write to participate in an io_uring event loop, even though that code was not written with such use case in mind. Or, resource leak detection could be enabled for third-party C code. For now this is only a vaporware idea which has not been experimented with, but the idea intrigues me.

The immediate goal is to replace all the C code we bundle from musl, wasi-libc, and MinGW-w64 with Zig code. So if you cross-compile for those libcs with static linking, you get Zig's libc which is API/ABI-compatible. In the future, it's entirely possible that we could expand the scope of Zig's libc to also be API/ABI-compatible with the statically-linked libcs from FreeBSD, NetBSD, etc. (We don't currently bundle the static C code for those.)