Solving Common Pointer Conundrums - Loris Cro 

Your comment is failing to compile (line 3 > error: Like, I knpw it wasn't meant)

I thought sometimes it is simpler to just introduce the concept right away than to waste time explaining why not to do so. Concept of a pointer is not difficult if visualized well

@@seanknowles9985 parsing error: "Like, I knpw it wasn't meant" found on line 4

pointer is a stupid abstraction, use raw adresses like a pro

fonts.google.com/specimen/Press+Start+2P

I'm not perfect at describing weird pointer combos, but in general the important part is that [*] is a pointer to an item, and all the brackets are telling you that by adding sizeOf(MyType) to that pointer you might have another instance of MyType. The way you can know that's the case or not is through a separate scheme (e.g. you have a second argument that conveys how many, or you know there's going to be a sentinel instance of MyType that tells you it's the end of the line). So with that in mind, *[*]T means that you have a pointer pointing to a pointer to T, so you have a **T, but you know that the pointer you get by dereferencing the initial value, might have other Ts in front of it. So if `a` is the original value, `a.*` is a pointer to T, `a.*[1]` is a T (index access to a pointer adds the size and dereferences). I hope that is a good explanation, also take a look at the compileLog messages in this snippet: zig.godbolt.org/z/EYzrqT

@@kristoff-it That was a very clear explanation, thank you!

@@kristoff-it I think your description in your response to Balen is correct, from looking at the Zig docs and the compileLog link you gave. But I think that means that your first two explanations (17:54) must be wrong... or at least a slip of the tongue. shouldn't they both have one more level of indirection than you said because the [ ] are also a dereference themselves.

@@shoulderstack5527 I think I might have used "sequence" and "sequence of pointers" a bit too liberally (to mean the same thing). Looking at the timestamp you linked, the first example is a single pointer that, when dereferenced, brings you to an array of pointers to MyType, but you don't know the length of that array. So to get to an instance of MyType (so not a pointer-to, but straight up a MyType value) you would write something like `my_var.*[2]`. The second example has the array in the outer layer, so you'd need to do `my_var[2].*` to obtain a MyType. Of course, this is all assuming the [*] have enough elements to accommodate for my example.

@@kristoff-it Also, I wanted to say 'Thanks so much' for these Zig Showtime and the Advent of Code videos. They really help to lower the cost of entry for someone like me. It means I can afford to devote some time to finding out if Zig is a good choice for me because you made it so easy to explore. Thanks!

Null (address 0) represents the nil case of an optional value. This is similar to Rust's null pointer optimization where for instance the size of Option is the same as the size of &T. The 'nil' case can be safely represented as address 0 because pointers in rust (and zig) cannot be null.

​@@shilangyuoh that's interesting, nil is reserved by virtue of it being illegal on raw pointers. Makes sense now thanks.

@@HairyPixels Yeah basically Optional pointers in Zig or Rust are just syntactic sugar for branching on null. The equivalent in C would be : foo() { ... stuff happening. my_type *ptr = memory_reference_of_something(); if (ptr == NULL) // aka pointing at address 0. return (error); ... stuff happening. } The problem with null pointer is that they can be null, and if they are not systematically checked than it's a big deal, Optional, put that burden on the type system and the compiler. In Zig or Rust you can't access a pointer unless you are explicitly acknowledging that it can be null, either by handling the null case, or by assuming it to be unreachable.