These videos are SO good. I don’t know how you’ve got the time and the energy to keep making them, but honestly you’re beating any written guide or documentation I’ve seen on Zig, anywhere.
Man the . notation on pointers really breaks my C++ trained mental model. When you set Y based on address of X, that line screams “you’re setting the temporary, stack-allocated instance, not the original struct”. I actually really love Zig so far, but find it really confusing to have to refer back to the declaration of the constant/var to figure out if I’m dealing with a pointer to the heap or a stack allocated variable. NGL I think I’ll miss the -> operator
Agreed, this is a very convenient syntax sugar, but can be cause for confusion and errors. I guess these are the tradeoffs that have to be weighed when designing a language.
This is fantastic.. with one exception.. when you talked about the separate Point.zig file, the syntax y: f32.. it has no var, const, etc before it. I get that having the const Point = @This is similar (or is it identical) to the const Point = struct {} in the other file. But is it valid to have a .zig source file with the y and x defined above? Seems like there is nothing indicating if they are const, var, etc. Also.. maybe I missed it, but when I import Point.zig, and having the @This const in there.. does that basically now make the function new and distance part of the struct @This const? So identical to the way it's defined in the first file? Lastly.. why.. why would you ever do this? It seems harder to read and serves no purpose that I can see. Why not in Point.zig have the actual const Point = struct { ... } so its readable/clear that its a struct, and the two functions are methods (or namespace and method)? So what is the benefit of doing this? I asked Bard this question and it came back with basically saying that @This approach is good for generic declarations inside a function, but it didnt indicate using a separate file with this sort of code layout.
You totally can put the const struct = Point definition in another file instead of using the entire file as the struct definition and having to use @This to reference itself. Then when you @import you would @import("point.zig").Point. I guess the answer to all your questions is "flexibility and consistency". Zig lets you define a struct in several ways but no matter how you do it, structs are always anonymous and are named according to the rules of the compiler. One advanteage to the entire file as the struct is that you can start with an inline `const struct = ...` style and over time if the struct grows large and complex you can just crete a new file, copy and paste everything between the {} and add @This, and you're done.
@@dudethebuilder Ah.. ok.. that is cool then. I just wasn't sure if there was one way or another "the right way". Sounds like either are perfectly fine with the individual file offering a little more separation/organization. Thank you.
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
These videos are SO good. I don’t know how you’ve got the time and the energy to keep making them, but honestly you’re beating any written guide or documentation I’ve seen on Zig, anywhere.
another great video, thanks!
Man the . notation on pointers really breaks my C++ trained mental model. When you set Y based on address of X, that line screams “you’re setting the temporary, stack-allocated instance, not the original struct”.
I actually really love Zig so far, but find it really confusing to have to refer back to the declaration of the constant/var to figure out if I’m dealing with a pointer to the heap or a stack allocated variable.
NGL I think I’ll miss the -> operator
Agreed, this is a very convenient syntax sugar, but can be cause for confusion and errors. I guess these are the tradeoffs that have to be weighed when designing a language.
great vid as always!
This is fantastic.. with one exception.. when you talked about the separate Point.zig file, the syntax y: f32.. it has no var, const, etc before it. I get that having the const Point = @This is similar (or is it identical) to the const Point = struct {} in the other file. But is it valid to have a .zig source file with the y and x defined above? Seems like there is nothing indicating if they are const, var, etc. Also.. maybe I missed it, but when I import Point.zig, and having the @This const in there.. does that basically now make the function new and distance part of the struct @This const? So identical to the way it's defined in the first file? Lastly.. why.. why would you ever do this? It seems harder to read and serves no purpose that I can see. Why not in Point.zig have the actual const Point = struct { ... } so its readable/clear that its a struct, and the two functions are methods (or namespace and method)? So what is the benefit of doing this? I asked Bard this question and it came back with basically saying that @This approach is good for generic declarations inside a function, but it didnt indicate using a separate file with this sort of code layout.
You totally can put the const struct = Point definition in another file instead of using the entire file as the struct definition and having to use @This to reference itself. Then when you @import you would @import("point.zig").Point. I guess the answer to all your questions is "flexibility and consistency". Zig lets you define a struct in several ways but no matter how you do it, structs are always anonymous and are named according to the rules of the compiler. One advanteage to the entire file as the struct is that you can start with an inline `const struct = ...` style and over time if the struct grows large and complex you can just crete a new file, copy and paste everything between the {} and add @This, and you're done.
@@dudethebuilder Ah.. ok.. that is cool then. I just wasn't sure if there was one way or another "the right way". Sounds like either are perfectly fine with the individual file offering a little more separation/organization. Thank you.
I guess another advantage of putting the struct definition inside its own file is that you now have private variables and functions.
amazing!!