Komari Spaghetti
Komari Spaghetti
How would we handle: * `*T` -> `[*]T` -> `*T` * `*T` -> `fn(...) ...` -> `*T` * `fn(...) ...` -> `fn(...) ...`
@alexnask What? I mean the use-cases that the current `@ptrCast` does just fine: ``` fn q() void {} test "" { const a: u8 = 0; const b = &a;...
I guess that could be `@intToPtr(*T, @ptrToInt(func))`. I think `fn` -> `*T` is really rare, while `*T` -> `fn` is more "common". Edit: Wait no. If you got a `*T`...
Discarding attributes is a very unsafe operations. You can easily discard attributes you don't want to discard with `@ptrCast` when you refactor code. It's to powerful. That is probably why...
> `0.15.0-dev.703+597dd328e` That's not Zig version 0.15.0. Looking up the commit hash really fast reveals a commit before 0.15.0 was release https://github.com/ziglang/zig/commit/597dd328e
Yea, giving an allocator to the value parsers is pretty useful. Instead of allowing both signature `fn ([]const u8) !T` and `fn (std.mem.Allocator, []const u8) !T`, I'd prefer to always...