06:03 <very-mediocre> just saw this: `very-mediocre, can you elaborate on caching comptime computed consts? zig already caches all comptime function calls`

06:04 <very-mediocre> I have a top-level const declaration that computes 500 primes, compile time is quite lengthy when using `zig test` on this file

06:04 <very-mediocre> it's still just a few seconds, but definitely noticeable

06:04 <andrewrk> ah I see, caching between invocations

06:04 <very-mediocre> (ping andrewrk)

06:04 <andrewrk> I have a plan to do that

06:04 <very-mediocre> i see!

06:05 <andrewrk> I am exploring this concept this week in the self hosted compiler

06:05 <very-mediocre> re:`very-mediocre, what do you mean about continuation expressions? I'm not aware that we have those` -> i meant "continue expression" i.e. while (condition) : { expression }

06:06 <very-mediocre> 100% personal feedback about this of course, I feel it breaks the principle of not having unnecessary things, and it's not that consistent to have : denote this

06:06 <andrewrk> I updated the docs to say "continue expression"

06:06 <very-mediocre> right, I just checked the docs because I knew I'd seen it there :)

06:07 <andrewrk> I appreciate the feedback. This feature is here to stay - it's the same thing as the final expression in a C for loop

06:07 <very-mediocre> Understood

06:07 <andrewrk> good night

06:08 <very-mediocre> bye

06:08 <very-mediocre> gn

06:28 <unique_id> very-mediocre: "that's a limitation of using functions that return structs, the namespacing becomes annoying" - You have to do the very same thing in languages that don't use anonymous structs. C++: using T = Type<bool>::InnerType; It's not annoying IMO, it's the proper way.

06:35 <unique_id> Bas_: HashMap(...) returns a type. init returns an instantiation of that type.

06:36 <unique_id> Bas_: Well.. I don't know if it's correct to say that HashMap(...) returns a type, or I should say it does so at compile time. It refers to a type.

06:38 <unique_id> Or you think of HashMap(...) as being a type, like std::vector<int> is a type in C++

06:38 <unique_id> could*

06:52 <very-mediocre> It's "proper" but still a bit of a niggle

06:52 <very-mediocre> Let's be honest, zig doesn't really have many "major" problems

06:52 <very-mediocre> imho it's already mostly better than C

06:54 <very-mediocre> I mean no "major" design problems

07:23 <stratact> Well Zig can't just be a "better C," it has to be a unique language in its own right which cater to the needs that no other language does, so that it would make people (especially companies) want to use Zig instead of something that's already maintain and in abundance. I think Zig having first-class debugging makes this language unique and attractive that many would want to try switch to.

09:25 <unique_id> andrewrk, there's a leftover "const fmt = std.fmt" in buffer.zig

13:58 <andrewrk> unique_id, thanks

14:55 <GitHub56> [zig] andrewrk closed pull request #1240: Allow for all integer types up to 128 bits. (master...issue-#745-allow-any-integer-type) https://git.io/fNYIu

14:55 <GitHub185> zig/master e9a03cc Andrew Kelley: all integer sizes are available as primitives...

14:55 <GitHub185> [zig] andrewrk pushed 1 new commit to master: https://git.io/fNOgl

16:00 <winksaville> I'm trying to run a particular test in the compiler, such as std/array_list.zig: test "std.ArrayList.swapRemove"?

16:00 <GitHub40> [zig] andrewrk pushed 1 new commit to master: https://git.io/fNO6Y

16:00 <GitHub40> zig/master d3ce9d0 Andrew Kelley: codegen: remove unused variable

16:00 <winksaville> I tried "bin/zig build --build-file ../build.zig test -Dtest-filter=std.ArrayList.swapRemove" and I got a bunch of "No tests to run." and then 173 "docgen example code 1/174...OK" but I don't see anything about std.ArrayList.swapRemove

16:01 <andrewrk> if you're trying to hit a specific test, I recommend this: bin/zig test file_with_the_test.zig --test-filter "foo"

16:06 <winksaville> andrewrk: txs, ./bin/zig test ../std/array_list.zig --test-filter "std.ArrayList.swapRemove" worked and reported:

16:06 <winksaville> Test 1/1 std.ArrayList.swapRemove...OK

16:07 <andrewrk> now you have a binary which only contains that 1 test

16:07 <andrewrk> so you can run it again with `gdb ./zig-cache/test -ex run`

16:09 <winksaville> But then I tired leaving off the --test-filter and ran "./bin/zig test ../std/array_list.zig" and it ran 612 tests, I was expecting it to run just the 5 tests in array_list.zig, what's happening?

16:09 <andrewrk> it's importing other files, and in each of those files they are importing other files, and zig ends up discovering all the tests

16:10 <andrewrk> it's why you can do `bin/zig test ../std/index.zig` and it tests all the standard library

16:10 <winksaville> got it

16:10 <andrewrk> some of the way this works may change, but I don't consider it to be a high priority

16:11 <winksaville> how do you run all of the tests in one file?

16:12 <andrewrk> there's no way to specify that to zig

16:13 <winksaville> interesting

16:14 <andrewrk> if you do `zig test file.zig` then it will at least run all the tests in that file

16:15 <winksaville> yeah, but 600 others also

16:15 <winksaville> in my case

16:32 <winksaville> So it seems the naming convention is used to limit tests and test-filter can then be used to do a simple 'starts with' syntax (no regex), correct?

16:35 <andrewrk> correct, except 'contains' instead of 'starts with'

16:38 <winksaville> Is "std.ArrayList.swapRemove" the new convention, the other tests are space separated english snippets in array_list.zig?

16:38 <andrewrk> there's no convention because I'm probably going to change how it works

16:38 <andrewrk> it's the wild wild west

16:39 <winksaville> :)

16:39 <winksaville> I was thinking I'd update the docs, but maybe to early for that?

16:39 <winksaville> (gtg, be back on line later)

16:40 <andrewrk> if you're looking for somewhere to contribute, my suggestion would be to build a simple project using zig, and then when you run into issues, work on those issues

21:37 <winksaville> in array_list swapRemove does not return an error how do you "catch" out of bounds errors?

21:37 <winksaville> I tried:

21:37 <winksaville> var val: error!i32 = list.swapRemove(0) catch |err| { std.debug.warn("caught err:{}\n", err); };

21:37 <winksaville> But the compiler says:

21:37 <andrewrk> swapRemove asserts that the index is in bounds

21:38 <andrewrk> you can tell because the return value does not have a possible error

21:39 <winksaville> ok, but swapRemove takes an index which can be out of bounds, I assume I can "catch" it some how?

21:39 <andrewrk> no, because the function does not return an error

21:40 <winksaville> So wouldn't it be prudent to have a swapRemoveOrError fn?

21:41 <andrewrk> no. any call to such a function would be a code smell

21:42 <andrewrk> why would you try to remove something that is out of bounds?

21:42 <winksaville> Because someone asked me to. Why is there a removeOrError but not remove?

21:44 <andrewrk> I forgot to delete that function when I merged somebody's PR

21:45 <andrewrk> you're right, it's inconsistent. we should either have the "OrError" variants or none of them

21:45 <winksaville> glad I got something right :)

21:46 <GitHub153> [zig] andrewrk pushed 1 new commit to master: https://git.io/fN3Le

21:46 <GitHub153> zig/master 9b56efc Andrew Kelley: remove std.ArrayList.removeOrError function

21:46 <andrewrk> winksaville, it's gone

21:47 <andrewrk> I recommend this line before your call to array.swapRemove: if (index >= array.len) return error.OutOfBounds;

21:47 <andrewrk> assuming that's what you want

21:48 <winksaville> Yea and why not have both swapRemove and swapRemoveOrError?

21:53 <andrewrk> I suppose that could be fine

21:57 <winksaville> There is a "fn pop(self: *Self) T" and "fn popOrNull(self: *Self) ?T" why both of these and not "fn popOrError(self: *Self) !T"

22:02 <andrewrk> what would the error be?

22:03 <winksaville> OutOfBounds or EmptyList

22:04 <andrewrk> that doesn't make sense for pop. pop doesn't need to assert that the list is non-empty

22:04 <andrewrk> if you wish to do this assertion, you can do list.pop().?

22:05 <andrewrk> list.pop() orelse return error.EmptyList

22:06 <andrewrk> one of the most important concepts in programming is to understand the difference between: normal runtime behavior, error handling behavior, and assertions

22:08 <winksaville> that seems to be a squishy statment, in the end to write "perfect" code we need to handle both, I think.

22:11 <winksaville> handling somethings with Null and other things with errors seems odd, but if that's the intent then I case swapRemoveOrNull would be prudent.

22:12 <andrewrk> swapRemoveOrNull is right out

22:13 <andrewrk> perfect code has assertions in it

22:13 <andrewrk> every statement which derefereces a pointer is asserting that the pointer is valid

22:13 <andrewrk> it would be incorrect, and in fact impossible, to make every pointer dereference return a possible error

22:13 <andrewrk> implicit assertions are a fundamental requirement of software

22:16 <winksaville> what do you mean by "swapRemoveOrNull is right out"

22:17 <andrewrk> I believe it is a british idiom

22:18 <andrewrk> it means "there is no doubt that this will not happen"

22:20 <winksaville> k, so you'd prefer popOrNull and swapRemoveOrError

22:23 <andrewrk> the way I would prefer all std library modifications is in the form of a pull request, with tests, and an explanation for the use case, ideally with a link to your open source zig project

22:24 <andrewrk> you can always make the modifications in the form of utility methods that are available in your project in the mean time

22:29 <winksaville> np, I'm trying to figure out the philosophy as array_list seems inconsistent. All of the inserts returning errors, then there is removeOrError but swapRemove didn't return an error and pop returning Null. Hence the questions.

22:31 <andrewrk> the std lib is not stable until 1.0.0

22:31 <andrewrk> right now it's mostly a test bed for the language

22:33 <winksaville> sg

22:53 <MajorLag1> For the record, I think I added a "orError" variation just because `set` had an `orError` variation.

23:03 <GitHub185> [zig] winksaville opened pull request #1253: Give ArrayList tests consistent names (master...give-std.ArrayList-tests-consistent-names) https://git.io/fN3Or

23:18 <andrewrk> MajorLag1, that makes sense

23:27 <GitHub52> [zig] andrewrk pushed 1 new commit to master: https://git.io/fN33x

23:27 <GitHub52> zig/master 0fa24b6 Andrew Kelley: allow implicit cast of undefined to optional