# Why . before field name in struct?

**URL:** <https://ziggit.dev/t/why-before-field-name-in-struct/2980>\
**Category:** Explain\
**Tags:** language\
**Created:** [January 23, 2024, 9:21am UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980 "2024-01-23T09:21:55Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![cdtogea](https://ziggit.dev/letter_avatar_proxy/v4/letter/c/ee7513/32.png) [@cdtogea](https://ziggit.dev/u/cdtogea)\
**Post date:** [January 23, 2024, 9:21am UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/1 "2024-01-23T09:21:55Z")

</div>

This works nicely:

```zig
const expect = @import("std").testing.expect;

const Stuff = struct {
    x: i32,
    y: i32,
};

test "01" {
	const thing = Stuff {.x = 10, .y = 20};	
	try expect(thing.x == 10);
}

```

Why do I have to use the . before x and y in the first line of the test?

Best regards,  
Catalin

---

<div class="post-metadata">

**Author:** ![tensorush](https://ziggit.dev/letter_avatar_proxy/v4/letter/t/6a8cbe/32.png) [@tensorush](https://ziggit.dev/u/tensorush)\
**Post date:** [January 23, 2024, 9:33am UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/2 "2024-01-23T09:33:30Z")

</div>

Such field initialization syntax is just easier to parse. Once the tokenizer sees a `.` after a block start `{` it can immediately tell that’s a field initialization, which means less ambiguity and more performance. The choice of `.` for field initialization is also consistent since you already write a `.` every time you access a field.

---

<div class="post-metadata">

**Author:** ![cdtogea](https://ziggit.dev/letter_avatar_proxy/v4/letter/c/ee7513/32.png) [@cdtogea](https://ziggit.dev/u/cdtogea)\
**Post date:** [January 23, 2024, 9:48am UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/3 "2024-01-23T09:48:26Z")

</div>

Thanks!

It seems strange to me, as this . is not necessary for field initialization in other languages, but I can understand that it is a design choice in order to speed up the parsing of the code. I was trying to understand if my code is doing something special because of the dot, besides just initializing the field.

I see that patterns/variations of .{} are used a lot in Zig. In this line of code:

```zig
std.debug.print("\nStuff = {}\n", .{@TypeOf(Stuff)});

```

Why do I need to have `@TypeOf(Stuff)` in a block and a dot preceeding the block?

Best regards,  
Catalin

---

<div class="post-metadata">

**Author:** ![tensorush](https://ziggit.dev/letter_avatar_proxy/v4/letter/t/6a8cbe/32.png) [@tensorush](https://ziggit.dev/u/tensorush)\
**Post date:** [January 23, 2024, 9:53am UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/4 "2024-01-23T09:53:31Z")

</div>

Yeah, so `.{}` is the [anonymous struct](https://ziglang.org/documentation/0.11.0/#Anonymous-Struct-Literals) syntax and here it’s used to be able to pass to the [`std.debug.print`](https://github.com/ziglang/zig/blob/0.11.0/lib/std/debug.zig#L86) a variable number of arguments. This design decision eliminates the complexity of having variadic functions like in C.

And again, such anonymous struct syntax is really easy to parse since by the time you parse `.{` you already know what it is.

---

<div class="post-metadata">

**Author:** ![matklad](https://ziggit.dev/user_avatar/ziggit.dev/matklad/32/2462_2.png) [@matklad](https://ziggit.dev/u/matklad)\
**Post date:** [January 23, 2024, 10:54am UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/5 "2024-01-23T10:54:21Z")

</div>

> [@tensorush](#):
>
> is just easier to parse.

It is also _tremendously_ easier to grep. If I want to learn where `foo` field is set, I can search for `.foo = `and that’ll give me all occurrences except for meta-programming via `@field`.

Now, of course, with good IDE support you can just the IDE to look for usages of `foo` which are only writes or inits. But good IDE support is still pretty thin these days, IIRC, LSP, for example, doesn’t allow expressing such a query at all.

---

<div class="post-metadata">

**Author:** ![tensorush](https://ziggit.dev/letter_avatar_proxy/v4/letter/t/6a8cbe/32.png) [@tensorush](https://ziggit.dev/u/tensorush)\
**Post date:** [January 23, 2024, 11:07am UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/6 "2024-01-23T11:07:24Z")

</div>

True, although be careful cause that also won’t give you the occurrences of default field values being set.

---

<div class="post-metadata">

**Author:** ![dude\_the\_builder](https://ziggit.dev/user_avatar/ziggit.dev/dude_the_builder/32/557_2.png) [@dude\_the\_builder](https://ziggit.dev/u/dude_the_builder)\
**Post date:** [January 23, 2024, 12:02pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/7 "2024-01-23T12:02:37Z")

</div>

I believe that this dot before field name syntax is also used in C, so this makes transitioning from C to Zig a bit easier too.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [January 23, 2024, 12:36pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/8 "2024-01-23T12:36:01Z")

</div>

> [@dude\_the\_builder](#):
>
> I believe that this dot before field name syntax is also used in C

That’s true, an example from some my code:

```zig
static struct modbus_cmd_descr xdcmf_readout_sequence[] = {
        [0] = {.func = 0x04, .sreg = 0x00E8, .nreg = 0x0002, .copy = true},
        [1] = {.func = 0x04, .sreg = 0x00F6, .nreg = 0x0008, .copy = true},
        [2] = {.func = 0x04, .sreg = 0x0100, .nreg = 0x000A, .copy = true},
        [3] = {.func = 0x04, .sreg = 0x0116, .nreg = 0x0008, .copy = true},
        [4] = {.func = 0x04, .sreg = 0x0124, .nreg = 0x0002, .copy = true},
};

```

Also note a comma (`,`) after the last element the array.  
Somewhere I saw in Zig it is also recommended to use comma after something that is currently last.

---

<div class="post-metadata">

**Author:** ![dude\_the\_builder](https://ziggit.dev/user_avatar/ziggit.dev/dude_the_builder/32/557_2.png) [@dude\_the\_builder](https://ziggit.dev/u/dude_the_builder)\
**Post date:** [January 23, 2024, 1:23pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/9 "2024-01-23T13:23:41Z")

</div>

Maybe you’re referring to this item in the [style guide](https://ziglang.org/documentation/master/#Style-Guide):

> - If a list of things is longer than 2, put each item on its own line and exercise the ability to put an extra comma at the end.

So for example in a function call, if it takes less than 3 args you write it like:

```zig
func(arg1, arg2);

```

But if it takes 3 or more, you write it like:

```zig
func(
    arg1,
    arg2,
    arg3,
    arg4,
);

```

Zig fmt will automatically format it as per the style guide if you put the comma after the last item.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [January 23, 2024, 2:11pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/10 "2024-01-23T14:11:46Z")

</div>

> [@](#):
>
> and exercise the ability to put an extra comma at the end

Yes, this is it.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [January 23, 2024, 2:28pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/11 "2024-01-23T14:28:19Z")

</div>

Just a quotation from [here](https://www.openmymind.net/learning_zig/language_overview_1/):

> If you’re like me and not a C++ programmer, the syntax to initalize fields, `.$field = $value,` might be a little odd, but you’ll get used to it in no time.

> [@tensorush](#):
>
> The choice of `.` for field initialization is also consistent since you already write a `.` every time you access a field.

I take dots in fields’ initialisers exactly like this - it is consistent with dots when accessing fields.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [January 23, 2024, 7:09pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/12 "2024-01-23T19:09:48Z")

</div>

> [@](#):
>
> If a list of things is longer than 2, put each item on its own line

I think there are cases when putting more than 2 (btw, why two, why not three or five?..)  
things on one line would be more readable than putting them on separate lines.  
This is something like my C example above, but in Zig, and I kept that rule:

```zig
const std = @import("std");

const ModbusCmndDesc = struct {
    func: u8,
    sreg: u16,
    nreg: u16,
};

pub fn main() void {

    const someCmdSequence: [3]ModbusCmndDesc = .{
        .{
            .func = 0x04,
            .sreg = 0x00AA,
            .nreg = 1,
         },
        .{
            .func = 0x04,
            .sreg = 0x00BB,
            .nreg = 1,
           },
        .{
            .func = 0x04,
            .sreg = 0x00CC,
            .nreg = 1,
        },
    };

    for (someCmdSequence) |c| {
        std.debug.print("{}\n", .{c});
    }
}

```

Now note the output:

```zig
$ ./aa 
aa.ModbusCmndDesc{ .func = 4, .sreg = 170, .nreg = 1 }
aa.ModbusCmndDesc{ .func = 4, .sreg = 187, .nreg = 1 }
aa.ModbusCmndDesc{ .func = 4, .sreg = 204, .nreg = 1 }

```

Zig itself (well, a function from standard library) ouputs each struct on a single line.  
So why can’t I do this in source code? 🙂

For me

```zig
   const someCmdSequence: [3]ModbusCmndDesc = .{
        .{.func = 0x04, .sreg = 0x00AA, .nreg = 1},
        .{.func = 0x04, .sreg = 0x00BB, .nreg = 1},
        .{.func = 0x04, .sreg = 0x00CC, .nreg = 1},
    };

```

is more readable, just because it naturally has a form of evenly aligned 2-dim table  
(provided that names of fields are of the same length, of course). When checking some particular field, it is more convenient to have all instances of that field to be in one _column_,  
due to a way how our vision works.

---

<div class="post-metadata">

**Author:** ![AndrewCodeDev](https://ziggit.dev/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@AndrewCodeDev](https://ziggit.dev/u/AndrewCodeDev)\
**Post date:** [January 23, 2024, 7:20pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/13 "2024-01-23T19:20:34Z")

</div>

I see your point and I agree with you that it’s more readable.

I encourage you to open a new thread about this topic if you want to continue the discussion about style guides.

---

<div class="post-metadata">

**Author:** ![nurpax](https://ziggit.dev/user_avatar/ziggit.dev/nurpax/32/1217_2.png) [@nurpax](https://ziggit.dev/u/nurpax)\
**Post date:** [January 23, 2024, 7:38pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/14 "2024-01-23T19:38:35Z")

</div>

Zig fmt supports this formatting too. You’d need to drop the trailing commas from within the inner struct values and it should be laid out like you want it to.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [January 23, 2024, 7:53pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/15 "2024-01-23T19:53:59Z")

</div>

> [@nurpax](#):
>
> You’d need to drop the trailing commas from within the inner struct values and it should be laid out like you want it to

Oh, thanks for this! I did not know .  
So, it seems that formatting/style rules are:

- with trailing comma put every item on it’s own line
- without trailing comma put everything on single line if you want/like it.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [January 23, 2024, 8:05pm UTC](https://ziggit.dev/t/why-before-field-name-in-struct/2980/16 "2024-01-23T20:05:07Z")

</div>

> [@AndrewCodeDev](#):
>
> I encourage you to open a new thread about this topic if you want to continue the discussion about style guides.

Oops, sorry, that was a bit of off-topic, of course.  
I do not think it is worth special thread.