Interfaces. Oh my god, interfaces.
1 Like
remove comptime_int and comptime_float, I have no idea why they need to exist in the first place and they make my life miserable whenever I need to do any kind of meta-programming that is supposed to work for all the types.
2 Likes
I’d love to see an example of the kind of pain you’re experiencing here. Being completely ignorant on the subject, and grepping the docs for comptime_int, it seems like these types exist for optimization reasons?
I did not dive deep into comptime_int and comptime_float and also am a bit confused by it.
Why do they exist when there is anytype?
I hope this article helps
1 Like
this isn’t a full reason, but note that anytype can only be declared as the type of a parameter to a function, whereas const x: comptime_int = -19; is perfectly legal.
you can observe one reason that you might want comptime_float by opening up math.zig within std and seeing that math.pi is just … written out in all its large-number-of-decimal-places glory. that constant cannot be represented to that degree of specificity in memory as an f16, f32, f64 or even f128 or f80, whichever is the biggest legal Zig float type.
i know that you were just complaining, @cztomsik, rather than asking for advice, but i rarely run into problems with these types lately when doing anytype metaprogramming. if @TypeOf(x) gives you comptime_float, for instance, you could give it an explicit type (const y: f64 = x) and either keep going within the function, or just call the function again with y instead of x
1 Like
true! It’s so bad when there’s no proper IDE, when variables disappear when debugging in VS Code, and so on…
clear separation (in libriries i mean) of
- i/o stuff, including connect, also data storage device ops
- purely MEM/CPU bound things, like data structires (arrays, queues, stacks whatever)
this is one of the things i’m excited about for std.Io, making that something you can in principle read off from a function’s signature.
1 Like
i meant this way of thinking
different things in different zig versions, in zig16 it’s dereferencing pointer for the comptime type. typeof 123 when you write test is comptime value, so if you take that value, copy it, and then pass pointer to that copy, you cannot deref it anymore. so you need to do @as(xxx, ...) in all such places. why do I need to make a copy and pass a pointer? in this case it was because I wanted to have something like &dyn Any for templating and that’s a pointer, but there were other cases before, and you can just grep github to see for yourself:
1 Like
see my previous reply, @TypeOf(anytype) is ok as long as you are always passing by value. but when you mix tuples, pointers and comptime numbers, it’s a bit trickier. and tests often contain tuples with numbers, and those are comptime types.
1 Like