03:11 <emekankurumeh[m]> does the freebsd ci even work? when i submit a pull request that has missing include files it builds just fine.

04:18 <andrewrk> emekankurumeh[m], here are the tests run by the freebsd ci: https://github.com/ziglang/zig/blob/master/.builds/freebsd.yml

06:55 <kristate> andrewrk: hey, are you online?

06:57 <andrewrk> hi kristate

06:57 <kristate> hey

06:57 <kristate> thinking aloud about #1953, but I always wondered why we allow undefined behavior in the first place (instead of using the error infrastructure).

07:01 <andrewrk> kristate, consider that the `+` operator can invoke undefined behavior

07:01 <kristate> andrewrk: right, for these things, at the moment, we would have to panic, but for function calls where we can catch such things, wouldn't it be best to use the error infrastructure?

07:02 <andrewrk> go on

07:04 <kristate> andrewrk: well, we already have the compiler infra in place for calling-out to panic, so I wonder why we couldn't simply return an error up the stack instead of generating code to panic?

07:06 <kristate> likewise, it might make sense to have a special builtin for @intToPtr when the int is zero, ala @zeroPtr and then make @intToPtr try-able,

07:07 <kristate> try @intToPtr([*]const u8, 0) would generate an error.ZeroPointer (for example)

07:08 <kristate> likewise, @intToPtr might be called with a runtime variable that is zero, or another address that might be out of bounds

07:11 <kristate> right now, if you use try in a function that does not handle errors, the compiler complains, and that gives visibility to the programmer

07:14 <andrewrk> that's an interesting idea

07:15 <kristate> think of it this way, I know that we want @intToPtr to map as close as possible to llvm intrinsics, but at the same time, you would check code anyway to see if it equals a nullptr or not. try @intToPtr provides a very zig-way to do it, without the tacky if statement

07:15 <andrewrk> what do you think should happen on implicit cast from C pointer to Zig pointer? e.g. `[*c]u8` to `*u8`

07:19 <kristate> well, I think that there should first be a built-in to do it. it shouldn't be something you can just cast-down to. second, coming from C-land, a nullptr is technically not defined as 0, but is implemented as zero, so I think that this should be impossible: it should only be down-castable to ?*u8

07:21 <kristate> andrewrk: this is debatable and something like bikeshedding, but perhaps ptr to zero should only be available as a [*c] ptr

07:21 <kristate> would we ever have to cast down to *u8?

07:26 <andrewrk> kristate, are you familiar with the motivation behind #1059? are you suggesting only that casting *to* zig pointers should not be implicit, or also *from*?

07:27 <andrewrk> also, I apologize - I am a bit past my bedtime and I'm sure that I am not speaking with as much clarity as normal

07:31 <kristate> andrewrk: please by all means, get some rest :-) about #1059, I am really glad that it is happening and fully supportive of it

07:33 <kristate> andrewrk: maybe we can talk later about this subject. I will post this log as a comment on #1952

07:33 <andrewrk> sounds good to me

07:33 <andrewrk> good night

07:34 <kristate> good night

13:23 <DutchGh0st> have you guys seen this talk? https://www.youtube.com/watch?v=tcyb1lpEHm0

13:24 <DutchGh0st> Which makes me realize, all the fancy constexpr if stuff he talks about, queries you can make like "does type x have method z?", you can all do in zig *currently*, right?

13:43 <emekankurumeh[m]> i think so, it's just going to be very verbose

13:45 <DutchGh0st> the examples he shows in the D language also are verbose

15:30 <euantor> Endrei is very heavily involved with D if I remember correctly. I remember seeing a video where he was tlaking about some interesting stuff they do with strings, but unfortunately I can't find it now

15:33 <MajorLag> emekankurumeh[m]: it isn't verbose if you use the stdlib: `const has_fn = std.meta.trait.hasFn("fnName")(Type);`

15:34 <emekankurumeh[m]> I forgot about meta

16:01 <ross_k> Hi, I'm trying to build the tetris demo (https://github.com/andrewrk/tetris) on Windows with zig 0.3.0. I've set up the include/link paths to GLFW and epoxy, and the last thing it's complaining about seems to be printf:

16:01 <ross_k> error: no member named 'printf' in 'C:\Users\Ross\Downloads\tetris-master\src\c.zig' _ = c.printf(c"Error: %s\n", description);

16:01 <ross_k> Tried running from the VS2015 developer command prompt

16:01 <ross_k> (no difference)

16:02 <ross_k> Final zig command line is:

16:02 <ross_k> C:\Users\Ross\Downloads\zig-windows-x86_64-0.3.0+8e68d43a\zig.exe build-exe C:\Users\Ross\Downloads\tetris-master\src\main.zig --cache-dir C:\Users\Ross\Downloads\tetris-master\zig-cache --output C:\Users\Ross\Downloads\tetris-master\zig-cache\tetris.exe --name tetris --library c --library epoxy --library m --library png --library glfw --library z

16:03 <ross_k> Is there an extra step I'm missing to point zig to the MSVC stdio?

16:05 <ross_k> It might be related to https://github.com/ziglang/zig/issues/558

18:50 <andrewrk> hi ross_k, I think I didn't get it building on windows yet.

18:52 <andrewrk> oh, I see you got it building though - I think what happened is @cImport wasn't able to understand the way printf was defined in stdio.h (maybe it was a weird macro or something)

18:52 <andrewrk> we can have a look at the .h file and see if that can be improved

21:32 <schme245> is there an issue for something like Jai's "using" keyword in Zig?

21:33 <schme245> I tried to check on GitHub but that word is hard to search for!

21:33 <andrewrk> schme245, that's where you embed one struct's fields into another, yes?

21:34 <schme245> it might be used for that as well, the use case I'm thinking of is where it brings a structs variable into the scope

21:35 <andrewrk> I believe these are relevant: https://github.com/ziglang/zig/issues/1214 https://github.com/ziglang/zig/issues/985

21:39 <schme245> well, not really, the case I'm thinking of is more of a syntactic convenience

21:40 <schme245> here's an example: https://gist.github.com/schmee/5a685f7a65961828838b2f0a798e66f2

22:06 <andrewrk> oh I see, you want to use the fields of the struct

22:07 <andrewrk> I don't think that has been proposed, and I would predict resistance to that proposal from myself and others as well

22:11 <schme245> yeah, I kinda figured since it's pure typing avoidance and I know what Zig's stance on that is, but just wanted to throw the question out there!