03:24 <andrewrk> coroutines proposal is up

03:35 <andrewrk> https://github.com/zig-lang/zig/issues/727#issuecomment-366856402

10:13 <achamb> has any thought been given to things like restricted ranges for integer types in zig?

10:13 <achamb> seems like a safety mode sort of thing

10:14 <achamb> e.g. an integer that must be in the range 0-59

10:14 <achamb> or 1-12

10:16 <achamb> i think it is something ada has

12:36 <MajorLag_> Closest we have right now is arbitrary bit-length integers. In safe and debug mode those would be checked for range at runtime.

16:16 <jfo> achamb: I was actually thinking how much I would like that in the context of an index to a fixed length array. Like a modified usize. Then out of bounds access on the array would be synonymous with integer overflow for the derived type. I don't know how useful that would be in that context or if it's a thing that exists other places but it's a though

16:24 <andrewrk> achamb, I've been thinking a lot about this recently

16:24 <andrewrk> I haven't typed out any proposals

19:13 <sient> re https://github.com/zig-lang/zig/issues/781, is there a way to mirror the `struct Foo {}; REGISTER(Foo);` pattern in C?

19:14 <sient> (C -> C++)

19:32 <andrewrk> sient, what does REGISTER do?

19:33 <sient> depends, but what I have done in the past is register a static variable that has a ctor which constructs a singleton instance and adds it to a static list

19:33 <sient> I can share a link to code if need be

19:33 <andrewrk> yes please, may I see?

19:35 <sient> it is a bit messy, it starts here https://github.com/cquery-project/cquery/blob/ff4ff8666439e3da3ff77ed7cdc74670ed004b2b/src/language_server_api.h#L34 ; usage example at https://github.com/cquery-project/cquery/blob/db21dd896e91e2249938247f480860d9f078eaae/src/messages/cquery_vars.cc#L11

19:35 <sient> I used to maintain a list of all handlers, it would sometimes causes wasted time spent debugging due to forgetting to register

19:41 <andrewrk> sient, it looks like it still registers at runtime, but the difference is that now you can put REGISTER_IPC_MESSAGE below the type declaration instead of in the Run function. is that right?

19:46 <andrewrk> one strategy you could have in zig, is iterate over a list of modules (files) at compile time and instantiate them this way

19:46 <andrewrk> then you would get compile errors for not fulfilling the plugin interface or whatever

19:47 <andrewrk> the short answer to your question is no, there are no static constructors. but I really think you can accomplish the goals a better way with comptime machinery

19:47 <sient> ah, that'd be perfect - didn't realize comptime could introspect like this; is there a test for the feature I can look at?

19:47 <andrewrk> hm, no but I should add some

19:48 <andrewrk> maybe try this: https://github.com/Hejsil/fun-with-zig/tree/master/src/namespaces/namespace_array

19:48 <sient> yes, banning static ctors seems like a good idea ; chrome bans them outright due to startup time penalties

19:49 <andrewrk> as you noted, there aren't a lot of tests for things like this. if you run into bugs I'll try to get them sorted right away to unblock you

19:49 <sient> that example looks perfect, thanks

20:14 <MajorLag_> Pretty much any time I try to do something with (type)"var" other than take it as a comptime parameter it crashes the compiler. I'm mentioning this rather than continue to make bug reports.

20:15 <MajorLag_> Most of these should never be allowed anyway, I'm just poking around trying to see if I can make reasonable implementations of things that might otherwise be language features.

20:19 <andrewrk> MajorLag_, it's a mistake that "var" is allowed as a type. it's really just syntax that function parameters and return type can use

20:19 <andrewrk> I'll fix it in the parser soon

20:19 <andrewrk> it's not really a type

20:22 <MajorLag_> Yeah, I get that.

20:24 <andrewrk> I think we have plans for the stuff you're trying to do though

20:24 <andrewrk> right now you can't have a variable at compile time that gets assigned a different type

20:24 <andrewrk> that's a problem

20:25 <andrewrk> I think we need to make comptime variables support being assigned different types