00:22 <zachcarter> thanks!

02:33 <MajorLag> daurnimator: If we rename it to KernelAllocator I think we should change the Windows implementation to use VirtualAlloc directly. I've been thinking we should do that anyway actually, but I haven't bothered to check if it makes any real difference. My concern is that using HeapAllocator and large alignments might cause it to commit more memory than is actually required, but I haven't put the work in to check.

02:39 <MajorLag> Regarding allocator attributes, I'm not sure what the best way to do that would be. My instict is to say that it should be handled in a trait `pub fn myFunc(allocator: var<trait.hasFn("allocExecutable")>) !void { ... };` or something.

11:16 <IntoxicatedHippo> Is there a way to create an array from a slice? I have a function that returns [10]u8 and I want to get the value from an ArrayList.

12:03 <andrewrk> IntoxicatedHippo, https://github.com/ziglang/zig/issues/863

12:55 <DutchGh0st> what leaderboard o you guys have for AoC ?

17:58 <MajorLag> andrewrk, am I misremembering or was there talk of comptime fields in runtime structs at one point? I can't imagine how that would work, but it's the kind of magic that I suddenly find myself in a position to appreciate.

20:24 <andrewrk> MajorLag, yes that is planned

20:24 <andrewrk> it's the thing that will make tuples unnecessary

20:25 <andrewrk> DutchGh0st, https://www.reddit.com/r/Zig/comments/a1tnnn/official_zig_private_leaderboard_for_advent_of/

20:35 <MajorLag> andrewrk, is there a link to discussion of it and how it works? May be relevant to #1829

20:44 <andrewrk> MajorLag, I'll do a writeup to give it its own issue

20:44 <andrewrk> this is the only thing I wrote about it so far: https://github.com/ziglang/zig/issues/208#issuecomment-440504195

20:45 <andrewrk> consider that it is harmonious with https://github.com/ziglang/zig/issues/485, which is also accepted

20:46 <andrewrk> so you make your field comptime, give it its "default value" which is its only possible value, then omit the field in initialization. then the field is found when using @memberCount etc and can be found by accessing an instance, but is always comptime known

20:48 <andrewrk> I really need to get copy elision done

20:48 <andrewrk> implementing every other proposal will cause conflicts with the branch unless it's merged

21:54 <MajorLag> hmm... ok that isn't precisely what I imagined. What I was thinking was we could retain error set information in a runtime-interface struct in a field that had a comptime value and was only accessible at comptime. Roughly the equivelent of what I mentioned in #764 but with the comptime parameter embedded in the struct (but only for things that care about it at comptime... kinda like a tag).

22:00 <MajorLag> I mean, if it is only ever a default value, why not use a `pub const` instead of a field as it only ever changes when the type does?

22:28 <andrewrk> MajorLag, so that you can iterate over it with comptime reflection. This way you can pass a struct as a `var` parameter and that solves var args

22:29 <andrewrk> std.debug.warn("{} {}", .{x, true});

22:29 <andrewrk> or better example, passing a type, such as i32

22:30 <andrewrk> std.debug.warn("{}", .{i32});

23:32 <andrewrk> MajorLag, to further clarify, it will be recommended in general to not use this feature for the reason you explained, but it will get implicitly used for "var args" style functions where the function iterates over the fields at comptime

23:32 <andrewrk> I think it will be possible to not be aware that this is how it is working under the hood, and it will all still make sense intuitively

23:32 <andrewrk> I hope