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
Can you explain better what you’re talking about?
If you are asking about the reference to the result location, a possible reference is Go language’s reference to return values
Regarding the Zig language, my main expectation for it is that it can allow a variable to be converted as const without copying.
Based on the hypothetical grammar below, assume that using # before a block expression label means it can be used as a reference point within the block expression.
const config: Config = #config: {
var #config: Config = .init;
#config.setFoo(foo);
#config.setBar(bar);
break :#config;
}
In conjunction with RLS, this can eliminate the extra copies when converting variables to constants.
However, since RLS is about to be removed, this hope is basically shattered.
2 Likes
Why is that hope shattered? Seems to me that’s a compiler optimization question and not a language syntax question?
Yes, after removing RLS, my wish would become worthless, because there’s no longer any value in eliminating such duplication from a grammatical perspectiv; getting rid of it will rely on optimization instead.
And after some reflection, I’ve realized that the RLS syntax, which is meant to eliminate copying, can also be easily misused, leading code authors to overlook exception safety. So I support the direction Zig is evolving in, and I’m no longer hung up on the wish I first brought up at the start of this thread.
4 spaces indentation but this more of zls issue than zig 
i think the language is quite verbose and 2 spaces identation would make more sense
This is more zig, because zls uses zig fmt.
1 Like
Essay is good and funny, thanks
Makes it make complete sense to me now
More development news.
I am very excited about Zig and its development. I watch issues and pull requests. But at times it feels like nothing much is going on. I can understand that there is alot of work going on that I can’t see. Interesting challenges and difficulties unknown to me, decisions that I wouldn’t even even know about, exciting solutions and features, even if not directly visible to the language user.
I used to play game Factorio a lot, and the dev team used to do weekly blog posts about development. Nothing too long nor too technical. Just something little every week, maybe 3-5 minutes read. Small (and big) things to be shared with the community.
I would love if Zig had something like that going on. I can also understand that it is sort of a burden to the team. But maybe with recent core team expansion it could be possible? 
14 Likes