05:30 <andrewrk> copy-elision-2 is coming along

05:31 <andrewrk> it's a big core implementation change, probably the biggest since changing from AST codegen to the IR system

12:50 <bheads> That is such a big change! Have you done any performance comparisions yet?

13:01 <Hejsil> bheads I don't think it

13:01 <Hejsil> 's gonna make a big difference in perf in release-fast

15:46 <andrewrk> agreed. and I haven't benched anything, since most tests are failing. Also the change is semantically needed; performance improvement is not required for this to be valuable

15:46 <andrewrk> it will be interesting to see the difference in compilation speed and debug mode

16:38 <andrewrk> hmm. I either need to change implicit cast syntax to make it different than function call syntax, or add some complexity to the IR system to deal with the fact that we don't know whether something is an implicit cast or function call until pass 2 (when we have types)

17:52 <Rohlem> andrewrk: I guess I'm late, but is that distinction really necessary? I was under the impression that explicit casts (@intCast etc.) are just calls to builtin functions. So why couldn't "default" casts also be function calls? (with a special rule that calling a type like that is a cast)

17:53 <Rohlem> andrewrk: So I guess I'd be worried that casts-through function calls (like explicit casts) would have different guarantees/behaviour from non-function-casts, if that distinction is necessary.

17:55 <andrewrk> Rohlem, that is indeed one of the two potential solutions I'm considering: 1. make implicit casts a builtin, or 2. make status quo syntax continue to work (in progress)

17:56 <andrewrk> "implicit casts" are generally preferred to explicit ones, as they are always safe

17:56 <andrewrk> explicit casts are a surface area for bugs

18:01 <andrewrk> implicit casts will never go away - there are many places they happen - for example when you call a function, the arguments are implicitly casted to the parameter types. this makes, for example, string literals able to be passed to functions accepting slices

19:01 <DutchGh0st> `const` means just: This variable is immutable ?

19:02 <DutchGh0st> I dont know why, but I always though it was const as in...a constant const

19:10 <andrewrk> DutchGh0st, yes that's what it means

19:11 <andrewrk> you can think of it this way: "the bytes that make up this variable are constant"

19:11 <DutchGh0st> hehe

19:13 <DutchGh0st> Also I did not know you could use godbolt with zig now!

19:14 <andrewrk> in that case you probably have a lot more exciting things to read about in the 0.3.0 release notes: https://ziglang.org/download/0.3.0/release-notes.html

19:14 <DutchGh0st> `now`, maybe Im just late with updates or whatever, but I was excited when I read it while sitting in the train

19:16 <DutchGh0st> also I wondered, is there like some simd section in stdlib?

19:18 <andrewrk> simd is one of the high priority 0.4.0 issues https://github.com/ziglang/zig/issues/903

19:19 <DutchGh0st> \o/

19:29 <DutchGh0st> wasn't there a playground to online compile some code?

19:41 <andrewrk> https://tio.run/#zig

19:41 <andrewrk> I stopped linking to it because it doesn't update frequently enough, and doesn't have color support in the stderr output for errors

19:43 <DutchGh0st> ah yes,

19:44 <DutchGh0st> I tried to switch against a slice and an array, but that didn't work ^^

20:37 <andrewrk> Hejsil, one more thing that just occurred to me - we could have a coroutine frame, pre-suspended, be a comptime const value that you can initialize coroutine frames to

20:37 <andrewrk> you would use this for generators, for example. but it's neat that the pre-suspended value could be a comptime constant.

20:41 <andrewrk> hmm that doesn't take into account parameters. never mind.

20:42 <wink_> @andrewrk, is there a way to use the "test" directive to validate @compileError paths in generic code?

20:42 <andrewrk> no. there's an open issue for that

20:42 <wink_> k

20:46 <Hejsil> Puuh, this grammar work is killing me. I'll need to finish this up fast, as I've gotten the urge to work on the randomizer again, but work towards this https://github.com/Hejsil/pokemon-randomizer/issues/41

20:47 <Hejsil> andrewrk, seems that your copy elide work is comming along nicely btw.

20:48 <andrewrk> thanks. have you been looking at the examples in the commit messages?

20:48 <andrewrk> yeah, you've taken on a big project

20:49 <Hejsil> A little, but I'm not super fluent in LLVM, so a quick glance didn't say much :)

20:49 <andrewrk> the key parts are the lack of alloca instructions and memcpy instructions

20:49 <Hejsil> It's probably pretty simple, when you know the instruction set

20:50 <Hejsil> I'm looking forward to seeing if debug builds are build faster

20:50 <Hejsil> And I know of a few places where I could use the copy being elided

20:50 <andrewrk> yeah. I imagine it won't be by much. but theoretically it's less LLVM code, which is the slowest part of compilation

20:51 <Hejsil> It also seems that the tuple proposal has gone stale again. I'm still not sure what the solution is myself

20:52 <Hejsil> Adding tuples for multi return and varargs seems overkill, but my other proposals kinda feels like hacks

20:53 <andrewrk> let's start with anon enum initializers, anon struct initializers, and then maybe anon list initializers, and see where that takes us

20:54 <Hejsil> Agreed

21:03 <andrewrk> Hejsil, I'm interested in reverting the `struct.{` syntax changes, are you on board with this, and is the `anyerror` change sufficient to solve the problem?

21:10 <Hejsil> The PR does revert this, and I'm pretty sure anyerror is enough

21:16 <andrewrk> oh I see, you made the parser code according to the grammar you worked on

21:16 <andrewrk> wow, this is really high quality work

21:17 <andrewrk> if you run out of steam, I think this is still worth merging even if we leave the async hack in for now

21:51 <nbjoerg> andrewrk: seeing the compile-time perfect hashing post -- you are aware of the expected O(n) algorithms for creating phash functions?

21:51 <nbjoerg> just in case it is more than a pure fun example :)

21:53 <andrewrk> nbjoerg, neat- I figured there was probably plenty of academia around the concept. I just wanted to show a comparison of how it looks to implement compile-time stuff in c++ vs zig

22:01 <nbjoerg> I should find some time to look at zig more seriously. but just for #853 I can take it a lot more serious than many other languages...

22:03 <nbjoerg> heh and since you advertised the godbolt support: the first example link is currently broken as the compiler core dumps ;)

22:05 <andrewrk> I'll have a look at that. In the meantime, choosing 0.3.0 should be a stable workaround

22:12 <andrewrk> nbjoerg, hm so here's what happened. godbolt used to have zig 0.3.0 and master branch. the link in the release notes was pointing to master branch, which worked at the time. it seems that godbolt removed master and added 0.2.0 and now that link, which used to point to master, now chooses 0.2.0

22:13 <nbjoerg> heh