07:09 <grinz> const struct_type = @typeOf(Point); @compileLog(@typeId(struct_type));

07:10 <grinz> this code outputs "TypeId.Type". Is there a way to "dereference" struct_type so it will act as if I passed Point directly?

07:48 <andrewrk> grinz, const struct_type = Point;

07:48 <andrewrk> is that what you want?

07:57 <grinz> https://gist.github.com/anonymous/2af51c0ea79f62ec565546e9619ef470

07:57 <grinz> I cannot understand that difference

08:04 <grinz> Oh I got it. I was confused by return type of typeOf being "type"

08:18 <grinz> https://gist.github.com/anonymous/527e90e07b203eacd0b63f6be2412507

08:19 <grinz> What is the right way to return comptime value from a function?

08:29 <GitHub102> [zig] tiehuis opened pull request #784: Add utf8 string view (master...utf8-string-view) https://git.io/vA2il

08:41 <tiehuis> grinz: do the following: `comptime const info = comptime get_type_info(Point);`

08:42 <tiehuis> you don't need to explicitly specify the comptime on that variable either

08:42 <grinz> thanks

08:42 <tiehuis> so `const info = comptime get_type_info(Point);` will suffice

08:44 <tiehuis> i usually find you can do most everything you need by either calling a function with comptime or specifying a function argument as comptime

08:44 <grinz> why compiler ignores comptime specifier on return type? Or compiler automatically converts comptime value to runtime value unless you specify comptime on call site?

08:45 <tiehuis> i'm not sure the internals on that sorry

08:46 <grinz> You can also write struct { t: (comptime type) } with the same result

08:46 <grinz> Feels like a bug / missing check

08:49 <tiehuis> i think all function calls are runtime by default now unless explicitly specified with comptime

08:49 <tiehuis> this issue seems to suggest that while proposing for a way to prefer comptime evaluation where possible: https://github.com/zig-lang/zig/issues/425

09:16 <grinz> @memberCount(type) => no value count available for type 'type'

09:17 <tiehuis> what is the type in this case?

09:17 <grinz> But it has fields in some cases like (&u32).Child

09:18 <grinz> Where can I get all possible fields of type metaobject?

09:18 <grinz> like Child

09:18 <tiehuis> oh i see, let me see if i can find a list

09:24 <tiehuis> couldn't find a specific list but there are some uses here: https://github.com/zig-lang/zig/blob/master/test/cases/reflection.zig

09:25 <tiehuis> see also this issue which would make this information a little less opaque of implemented: https://github.com/zig-lang/zig/issues/383

09:58 <grinz> I want to make a function which return type depends on argument type. I implemented it is this way: fn return_type_test(comptime Type: type) map_type(Type) { ... }

09:59 <grinz> Does Zig have something like automatic return type inference so I can replace map_type(Type) with something like 'auto'?

10:17 <MajorLag_> Theoretically "var" should work as a return type, but that isn't handled currently. A workaround is to return "type", and then return a new empty struct type containing your data: return struct { var data = "Test"; };

10:19 <MajorLag_> If your comptime Type is the same as your return type though, you can just do this: fn return_type_test(comptime Type: type) Type { ... }

10:20 <MajorLag_> which you probably already know, but in case you didn't.

10:25 <grinz> so you are defining struct with no fields but with global variable in struct scope?

10:41 <grinz> https://gist.github.com/anonymous/1c5eb389aeacd9c5b894de338f918423

10:42 <grinz> My best attempt. Any ideas how to get rid of double function evaluation?

10:50 <MajorLag_> No, you'll have the same issue you have with the function you're calling inside your test function. You'd have to wrap it up in an empty struct and return it that way again. Or, since you know the two values types it could return you could use a union I suppose.

10:54 <grinz> can i use comptime string as field name when defining struct?

14:58 <GitHub113> [zig] bnoordhuis opened pull request #785: allow implicit cast from `S` to `?&const S` (master...fix731) https://git.io/vAaZ4

17:02 <MajorLag_> grinz, I don't think there's any way to do that today. I've wondered about doing that sort of thing myself.

17:04 <andrewrk> MajorLag_, I'll add return type inference

17:04 <andrewrk> do we have an issue yet?

17:05 <andrewrk> https://github.com/zig-lang/zig/issues/447

17:44 <MajorLag_> related: https://github.com/zig-lang/zig/issues/758

19:26 <MajorLag_> `.&` was an interesting suggestion. It looks weird, but it does have a certain logic to it, is unambiguous, clearly visible, and doesn't introduce any new symbols. I like it overall.

19:29 <MajorLag_> andrewrk, for block `[]` types, has t been considered to add a .size pseudofield? Like .len, but that gives @sizeOf(@typeOf(blockVar))*blockVar.len?

19:30 <MajorLag_> Because although that expression makes sense on the face of it, I believe it would be incorrect in the case of the new `[ ... ]null` types, since .len would not include the terminator.

19:30 <andrewrk> I accepted josh's updated proposal

19:31 <andrewrk> MajorLag_, hmm that's an interesting question

19:31 <andrewrk> I can't think of when I would use the size instead of the length in practice

19:31 <MajorLag_> In an allocator implementation?

19:32 <andrewrk> wouldn't you request exactly N bytes, and then get a []T?

19:33 <andrewrk> where does a null terminated pointer come into play?

19:33 <andrewrk> s/bytes/items/

19:33 <MajorLag_> I don't know, just kinda thinking out loud. I even took the wrong type in that expression.

19:33 <andrewrk> I think in practice the null thing will be clear and clean

19:34 <andrewrk> based on having written all the OS abstraction code

19:38 <MajorLag_> You'd have a better idea than I would, for sure. I haven't written any Zig yet that cares about C interfaces other than the handful of calls I make to SDL. Though I have some projects I'd like to use it for in the near future that would be interfacing with kernel APIs and probably a bunch of other C-oriented interfaces.

19:39 <andrewrk> I think most application developers could ignore the null terminated pointer types

19:39 <andrewrk> and if for some reason you have a null terminated pointer type, it implicitly casts to the other ones

19:48 <MajorLag_> Ok, well, thinking it through it's a pretty easy to comprehend rule: null terminates the block, it is not a part of it. So if it comes up and I have to fill a buffer with null terminated strings from a list of strings, the code would be consistent regardless of the kind of block in the source string list and I'd have to insert the nulls during the copy.

19:48 <andrewrk> exactly

19:51 <andrewrk> a null terminated pointer type is an assertion that there is a null/0 there. so you would make a []T of len N + 1, and then do something like this to get []null T: ([]null T)(slice[0..slice.len - 1])

19:51 <andrewrk> there would be a runtime safety check here (when not in release mode)

23:15 <grinz> What is the point of having dedicated []null T pointer syntax? Interop with C?

23:17 <grinz> It's rather limited. Let's say I want to write fast lexer. Null-terminated string are quite handy in this particular case but one terminated zero is not enought to get best perfomance.

23:18 <grinz> When SIMD comes into play, you want something like 15 trailing zeroes. And this is where new type become completely useless.

23:22 <grinz> But sometimes having these bytes readable is enough (i.e. guarantee that slice end is at least 15 bytes away from page boundary)

23:40 <grinz> https://gist.github.com/anonymous/44e529357cfe608096aa5005a8f02416

23:40 <grinz> Any ideas how to implement that without helper function?

23:47 <grinz> []null T is of no use if you want to interact with WinAPI which uses UTF-8 (2 trailing zero bytes)