Zig's dot star syntax (value.*)
68 comments
·March 7, 2025karmakaze
This is a weird (to me) way of presenting Zig syntax and operation. I would generally assume that someone coming to Zig would be familiar with C/C++ or Rust and only need to be able to map Zig syntax to things they already know.
If the author's content is all in this 'assume no C background' style, it will be useful to those without previous manual memory management background in contrast to most articles that assume a lot of context.
klodolph
This is the way that Pascal does it, which was always more sensible than prefix notation. Pascal uses ^
skissane
In C you can use `[0]` as a postfix dereferencing operation... ugly but it works. I use it a lot in GDB. But I agree that Pascal does it better here, the dereferencing operator should have been postfix all along.
The thing I really wish C had, and which there is no straightforward workaround for, is postfix casting. When you do `((struct foo*)(COMPLEX_EXPRESSION))->field`, I think it would read a lot better if the `(struct foo*)` cast was on the same side as `->field`. Maybe something like `(COMPLEX_EXPRESSION)@(struct foo*)->field`
pjmlp
In a way, Zig is Modula-2 with curly brackets for folks with C background.
Yes, I know, comptime and such.
loxodrome
Nice explanation of zig's dereferencing operator. Thanks!
nikolay
Good compiler, poor syntax. I'm waiting for the TypeScript equivalent for Zig.
epolanski
Do you find it poor just because it doesn't align with your experience and bias you hold from writing other languages?
alpaca128
Have you looked at C3? Its goals align with Zig but it’s much closer to C in terms of syntax.
markisus
Article says it’s about stack addresses but I think it should apply more generally to dynamically allocated memory as well.
copx
Tl;dr: It is just pointer dereferencing.
I.e. C's
*ptr
ptr.*
amjoshuamichael
Yeah I found this article super weird. Explaining pointers & dereferencing is reasonable, but doing it in the context of Zig specifically, like Zig is the first language to feature dereferencing, is odd. Especially since pointers are such a fundamental part of low-level (really, any) programming. Also not sure why it's posted here?
Edit: Going through this author's website, it seems like a lot of their posts are about rediscovering low-level programming concepts through Zig. Like this article, where they discover you can't compare strings directly, and you have to use memcmp:
https://www.openmymind.net/Switching-On-Strings-In-Zig/
They claim that they blog because they "find that [they] retain things better when I write about them." No problem with that. Just a little odd to see on the hn front page, I suppose.
wyldfire
> rediscovering
I think this is just "discovering". While you (and I) probably discovered these things with assembly or C languages, it's perfectly reasonable or even appropriate for newer generations to have these kinds of experiences with Zig or Rust.
amjoshuamichael
Absolutely, like I said, there's no problem with what this person is doing or the way that they're exploring computers, I'm just confused as to why it's being posted here.
TZubiri
Is it?
When learning piano you first learn how to play rudiments and then you move up to more complex scores.
Otherwise you end up writing an article about how Ravel' Scarbo is amazing because it involves playing with two hands at the same time.
LoganDark
Rediscovering is a perfectly fine word for one person discovering for the first time what others have discovered before.
cardanome
Yeah, I kept on reading to find out if there is some Zig-specific twist but it is literally just that.
Are there really that many Zig programmers that have never seen C or know what pointers are?
latch
Author here. I agree this is a less-than captivating piece. I write a lot about Zig and wanted something I could reference from other pieces.
But, to answer your question directly: absolutely. In addition to writing a lot about it, I maintain some popular libraries and lurk in various communities. Let me assure you, beginner memory-related questions come up _all the time_. I'd break them down into three groups:
1 - Young developers who might have a bit of experience in JavaScript or python. Not sure how they're finding their way to Zig. Maybe from HN, maybe to do game development. I think some come to Zig specifically to learn this kind of stuff (I've always believed most programmers should know C. Learning Zig gets you the same fundamentals, and has a lot of QoL stuff).
2 - Hobbyist. Often python developers, often doing embedded stuff. Might be looking to write extensions in Zig (versus having to do it in C).
3 - Old programmers who have been using higher level languages for _decades_ and need a refresher. Hey, that's me!
sundarurfriend
Hey, that's me too!
Also, from learning human languages, it's a well-known lesson that phrasebook-type "this means this" translations (like some here are asking, from Zig to C/Rust) are useful for quick and dirty learning good enough for one trip, but long term learning needs this kind of a direct explanation.
1. It avoids the word (or syntax in this case) getting stuck in a double-indirection state, needing you to mentally translate it from Zig to C to what it actually means every time.
2. It avoids the learner attaching the wrong nuances to the word or syntax feature, based on the translation they're given, when the language they're learning has different nuances. In other words, it helps the learner see it as its own thing, and not be unduly colored by what they already know and find easy to grasp on to (even when it's subtly wrong).
epolanski
> Not sure how they're finding their way to Zig.
Lots of popular Youtubers such as Primeagen (somebody who easily gets 200/300k+ views per video) have been speaking highly about Zig.
eaurouge
Perhaps add a brief paragraph, for C folks, that draws parallels between the Zig code and C. You never know, other readers may find it useful as well.
epolanski
I know some C but I haven't touched it in a decade, but I have started playing with Zig so this was useful to me.
You aren't always the target.
dmurray
It feels a bit performative to me: the article goes out of way not to explain it by giving the C equivalent.
Perhaps some day Zig will have replaced C and beginners will come to Zig having never touched C, and in that context this approach makes sense - after all, you wouldn't litter an introductory article on C with comparisons to Algol. But today, surely the modal Zig beginner already knows enough C that the syntax would better be explained by reference to C.
spacedcowboy
And why change something like that? The world would be a better place, IMHO, if there were less different ways to write something from language to language.
Sometimes it seems like the change is just to make it different, not better.
IshKebab
Same reason Rust uses foo.await instead of await foo. It's clearly superior syntax.
The whole point of Zig is to fix C's mistakes. I don't know why they'd repeat this one.
throwawaymaths
oh no. this is DEFINITELY a place where zig made a GOOD change away from c.
when a value is dereferenced, having a consistent left to right dereferencing makes sense.
for example, in c, without looking up the order of operations how confident are you that you know what is going on in the following:
foo = **bar[10]
sudahtigabulan
It's not just different.
This syntax is less arbitrary than C's. It draws a syntactic parallel between accessing a single member and accessing "all members". (by using pattern-matching-like syntax)
It makes the language more consistent and one's mental model of it smaller. (Even though I doubt that patterns other than the Kleene star would work)
A parallel with files:
cp dir/a dir/b dir/c /other/dir
cp dir/* /other/dir
cp *dir /other/dircassepipe
Yes, but unlike C's terribly confusing "declaration follows usage" style, which no tells you about btw, zig's pointer syntax doesn’t turn into a nightmarish puzzle.
In Zig, you can pretty much read the types aloud and it makes, your brain does not need to peek for parsing. For me it's too late, I got used to the C way but I still want the better thing to get adopted. No more int ((foo)(int))[5]; nonsense—just T, [N]T, or *T, making intent crystal clear.
toasterlovin
> Yes, but unlike C's terribly confusing "declaration follows usage" style, which no tells you about btw
I happen to be reading the K&R C book right now and they do in fact tell you this.
ajross
Yeah, not sure where that came from. The ANSI C standard was extensively documented in books and articles and specs at all levels of rigor starting from the mid-80's. No one has ever lacked for a reference for how function pointer declaration looks.
That said, C's function pointer declaration syntax is indeed awful. But really that's because ANSI took a very hardline "no incompatible changes" tact when adding prototypes to the language, which limited the ways they could express them. That decision is one of the reasons we're still writing C today. Any yahoo can come up with a new language, kids do it all the time. ANSI's job was to add features to the language in which Unix was already written.
silisili
I wonder why they went that route. At this point in my career the first notation is ingrained in my head. The bottom looks like regex.
FlyingSnake
FTA: “power.* is how we dereference a pointer“
This Is basically the gist of the article.
I’m surprised to see that so many programmers these days don’t know C and basic pointers.
xigoi
Everyone who knows pointers had to learn them at some point.
epolanski
Why would you?
Large parts of the industry does really work with low(er) level languages.
Even people who went through C/C++ in their formal education/start of their career may have not used it for a long time.
dazed_confused
Are you honestly surprised?
TZubiri
Probably a nitpick but
Didn't read, got bored at having pointers explained, even if actively trying to skip it.
I get a mix of: 1- you don't know your audience or are trying to cater to too wide of an audience
2- if someone doesn't know how pointers work, is there any merit in knowing syntax of a novel programming language?
So if you want the veterans to read this, you are going to have to make it less accessible.
Edit: it seems like the whole article is OP discovering pointers but zig is like his first language. Lol.
sureIy
I don't understand the snark. Is it not possible to write articles for beginners? There are also a lot of developers who have never dealt with memory allocation and are interested in Zig.
jvanderbot
That's the impression I got too.
However, thinking long term, are we going to continue to introduce pointers via C to new students? If not, then how? C++ or Zig seem viable options, so this might be a long term proposition.
Inb4 there won't be programmers
tcfhgj
Rust would be an option as well
jvanderbot
Rust does not in fact have a good way to introduce raw pointers that can be passed around, and can also be treated as addresses.
epolanski
Hey I started using Zig after a decade of JS/Elm/Haskell/php/scala, such articles are very useful to me. Haven't used lower lever languages in a long time.
You aren't always the audience, it's fine.
Didn't know anything about Zig, but the .* syntax alone was straight-forward and easy to understand, as is regular copying from one existing memory location to another.
I think what seems weird though is more the "... = .{...}" syntax.
This makes it look as if there was some kind of anonymous object ".{...}" in memory that you're copying from, but there isn't. It's actually just a writing operation and the .{...} itself doesn't represent anything.
Maybe that was also what the author found confusing?