In Zig? It would allocate stack space for a new variable a, and add b and the d field of c together and insert that value into the memory location that a reserved. In D or Python or anything that allows for properties, it would be allocating a where-ever the language allocates stuff, then calling an infix function '+' which could be anything depending on the language including starting up a JVM in the background for god knows what reason, and calls it with the arguments b and the result of calling the property function d of the object c.
But what are the types of those fields it is "adding"? What are the semantics of "adding" for those types? These things are not obvious from reading that statement.
They are obvious to the programmer who knows the types of b and d and thus the semantics of adding them.
The operation itself implies that both b and c.d must be primitive types and so the semantics of the operation are defined by Zig's language rules.
edit: To clarify - this in contrast to, say C++, where nothing can be inferred about the types of the variables involved and the semantics of the operation, since '+' can be overloaded.
The point of the example is that in Zig, that statement is exactly as simple as it looks.
What looks like a field reference (`c.d`) is just a field reference; there are no getters or @property functions that are doing more complicated things.
And similarly with the addition operator, that plus sign is just addition and doesn't call a function somewhere else.
These abstractions are considered useful by the designers of other languages, but they are specifically excluded in Zig. The benefit of not having them being that it's easier to follow the execution flow of the program.
I think the article is trying to say the plus and the dot access are guaranteed to be language built-ins and therefore be very cheap to call. Furthermore they can't fail by throwing exceptions or such. (Note that in C the plus operator may result in UB, such as signed overflow, or forming a pointer beyond one past the allocated size.)
No way to know without knowing the types and the mode used to compile it. If c is a pointer then it could be a panic or it could be undefined behavior (dangling reference), similarly if b is a numeric type then depending on how the program is compiled you will get different results.
