01:17 <andrewrk> Just got off a 5 hour plane ride. I almost have error sets done. This is gonna be great

03:39 <tiehuis> awesome, will be interested to play around with it. I've made some decent progress on a regex implementation, too: https://clbin.com/BLZ07

06:21 <MajorLag_> andrewrk, you around?

13:13 <tjpalmer> andrewrk, sounds great!

13:13 <tjpalmer> tiehuis, also sounds great! Is it compile-time parsed?

15:22 <MajorLag_> huh, actually, this isn't the comptime loop unrolling bug afterall

15:22 <MajorLag_> it's a completely new bug

16:31 <hasen_judy> has anyone tried using freetype with zig?

16:40 <GitHub139> [zig] andrewrk closed pull request #734: Made Zig support tabs (master...master) https://git.io/vNbSn

16:42 <hopppetosse> I'd very much like to be able to store sets of function arguments

16:42 <hopppetosse> sorry, that was meant to be up on a terminal =P

17:43 <MajorLag_> andrewrk: @TagType throws a compiler error when used on an extern union. I am unaware of a way to differentiate between extern and non-extern unions in reflection code, so cannot branch out of this.

17:44 <MajorLag_> The first solution that comes to mind is having @TagType return void in this instance

17:51 <MajorLag_> Interesting note: @tagName reveals the secret tag in a simple union.

20:58 <tjpalmer> tiehuis, well I guess that example won't be parsing regexps at compile time. But do you support that, too? And I haven't explored comptime much in zig. Would be possible today without hacking the compiler to generate code from a regexp?

21:02 <tiehuis> tjpalmer: the only thing needed is some sort of comptime allocator to allocate the nodes of the expression tree. otherwise all the parsing should actually be fine.

21:03 <tiehuis> It would be straight-forward to do an example backed by a fixed comptime sized array to test this.

21:05 <tiehuis> that would have a different interface of course, but to test that everything works at compile time

23:02 <jfo> andrewrk: I am curious about some things wrt structs and fns v "methods", small write up here : https://gist.github.com/7aa30e26738df634b247011b0912087b

23:17 <MajorLag_> >> // why isn't this internal to the struct? `pub` seems to not matter here. Pub lets importers use it

23:25 <jfo> it's the same effect if I import it though. the pub annotation on the struct itself works as expected but there seems to be no distinction inside the struct definition

23:33 <MajorLag_> huh, ok, I didn't realize that.

23:39 <jfo> my expectation would be for the pub keyword to expose "static" and/or "instance" methods outside the struct definition block

23:39 <jfo> terms being used loosely but, I think, appropriately

23:42 <jfo> (probably also "methods")

23:43 <jfo> I'm curious about the internals of structs actually now that I think about it. Does every instatiation carry around its own "method" copies? or is that optimized to a single function address?

23:45 <MajorLag_> the "methods" are just regular namespaced functions. The instance.func() syntax passes &instance as the first parameter (if it can) as a convenience.