ziglang/zig

Fork 765

Code Issues 704 Pull requests 287 Activity Actions 34

rename `@field` to `@member` for clarity #32029

New issue

Open

opened 2026年04月22日 21:04:54 +02:00 by andrewrk · 9 comments

andrewrk commented

2026年04月22日 21:04:54 +02:00

Owner

Copy link

Migrated (and mutated) from https://github.com/ziglang/zig/issues/3839

"fields" in zig have to do with struct fields for example.
"declarations" is our name for global stuff that is not fields.
"member" has some precedence for being either one or the other

@field is a.b syntax, it's not specifically for fields. For consistency, rename the builtin to @member.

Also for consistency, rename our "field access syntax" grammar to "member access syntax".

Migrated (and mutated) from https://github.com/ziglang/zig/issues/3839 * "fields" in zig have to do with struct fields for example. * "declarations" is our name for global stuff that is not fields. * "member" has some precedence for being either one or the other `@field` is `a.b` syntax, it's not specifically for fields. For consistency, rename the builtin to `@member`. Also for consistency, rename our "field access syntax" grammar to "member access syntax".

❤️ 8

andrewrk added this to the Urgent milestone

2026年04月22日 21:04:54 +02:00

andrewrk added the

accepted

proposal

breaking

labels

2026年04月22日 21:04:54 +02:00

castholm commented

2026年04月24日 00:04:08 +02:00

Contributor

Copy link

This proposal isn't dependent on but is closely connected to introduce @FieldEnum and use it for the operand type of builtins that accept a field name #23618, which proposes that @field should be changed to take a @FieldEnum(T) instead of []const u8. One of the comments points out:

Question: how does this apply to @field on a namespace? Currently you'd do @field(struct { const foo = 0; }, "foo"), but under this proposal, it would need to be an enum. Would we get an equivalent @DeclEnum for @field(type, @DeclEnum())?

If @field is changed to @member (instead of being split out into @field and @decl, as suggested by the original #3839), and if the @FieldEnum proposal were to be accepted and pursued, then a corresponding @DeclEnum builtin will be necessary to not lose the ability to access decls, and the @member builtin would need to behave rougly like:

@member(lhs:anytype,comptimemember:if(@TypeOf(lhs)==type)@DeclEnum(@TypeOf(lhs))else@FieldEnum(@TypeOf(lhs)))(member)

conststd=@import("std");test{constS=struct{x:i32,pubconsty:i32=2;};consts:S=.{.x=1};trystd.testing.expectEqual(1,@member(s,.x));// @as(@FieldEnum(S), .x)trystd.testing.expectEqual(2,@member(S,.y));// @as(@DeclEnum(S), .y)}

This proposal isn't dependent on but is closely connected to [introduce `@FieldEnum` and use it for the operand type of builtins that accept a field name #23618](https://github.com/ziglang/zig/issues/23618), which proposes that `@field` should be changed to take a `@FieldEnum(T)` instead of `[]const u8`. One of the comments points out: > Question: how does this apply to `@field` on a namespace? Currently you'd do `@field(struct { const foo = 0; }, "foo")`, but under this proposal, it would need to be an enum. Would we get an equivalent `@DeclEnum` for `@field(type, @DeclEnum())`? If `@field` is changed to `@member` (instead of being split out into `@field` and `@decl`, as suggested by the original [#3839](https://github.com/ziglang/zig/issues/3839)), and if the `@FieldEnum` proposal were to be accepted and pursued, then a corresponding `@DeclEnum` builtin will be necessary to not lose the ability to access decls, and the `@member` builtin would need to behave rougly like: ```zig @member(lhs: anytype, comptime member: if (@TypeOf(lhs) == type) @DeclEnum(@TypeOf(lhs)) else @FieldEnum(@TypeOf(lhs))) (member) ``` ```zig const std = @import("std"); test { const S = struct { x: i32, pub const y: i32 = 2; }; const s: S = .{ .x = 1 }; try std.testing.expectEqual(1, @member(s, .x)); // @as(@FieldEnum(S), .x) try std.testing.expectEqual(2, @member(S, .y)); // @as(@DeclEnum(S), .y) } ```

nektro commented

2026年04月28日 08:57:24 +02:00

Contributor

Copy link

@FieldType -> @Member should be included in this

`@FieldType` -> `@Member` should be included in this

EtienneParmentier commented

2026年04月28日 11:51:55 +02:00

Copy link

@member(lhs:anytype,comptimemember:if(@TypeOf(lhs)==type)@DeclEnum(@TypeOf(lhs))else@FieldEnum(@TypeOf(lhs)))(member)

conststd=@import("std");test{constS=struct{x:i32,pubconsty:i32=2;};consts:S=.{.x=1};trystd.testing.expectEqual(1,@member(s,.x));// @as(@FieldEnum(S), .x)trystd.testing.expectEqual(2,@member(S,.y));// @as(@DeclEnum(S), .y)}

I believe this examples shows a deeper problem with @field or @member: It can be used to access fields and declarations alike. I would rather prefer having 2 builtins: one for fields and one for members. It would disambiguate the two. Of course their could be breakage when one wants to access both field and declarations, but I can figure out a case where one would want that.

> ```zig > @member(lhs: anytype, comptime member: if (@TypeOf(lhs) == type) @DeclEnum(@TypeOf(lhs)) else @FieldEnum(@TypeOf(lhs))) (member) > ``` > > ```zig > const std = @import("std"); > test { > const S = struct { > x: i32, > pub const y: i32 = 2; > }; > const s: S = .{ .x = 1 }; > try std.testing.expectEqual(1, @member(s, .x)); // @as(@FieldEnum(S), .x) > try std.testing.expectEqual(2, @member(S, .y)); // @as(@DeclEnum(S), .y) > } > ``` I believe this examples shows a deeper problem with ```@field``` or ```@member```: It can be used to access fields and declarations alike. I would rather prefer having 2 builtins: one for fields and one for members. It would disambiguate the two. Of course their could be breakage when one wants to access both field and declarations, but I can figure out a case where one would want that.

nektro commented

2026年04月28日 12:06:18 +02:00

Contributor

Copy link

no, imo it only highlights that @member should stay using strings

no, imo it only highlights that `@member` should stay using strings

gschwind commented

2026年05月10日 17:13:46 +02:00

Copy link

Does this proposal include the rename of @fieldParentPtr ?

Maybe I would rename it @parentPtrFromMemberPtr ?

Does this proposal include the rename of `@fieldParentPtr` ? Maybe I would rename it `@parentPtrFromMemberPtr` ?

npc1054657282 commented

2026年05月10日 18:41:15 +02:00

Copy link

@gschwind I don't think so. The current @field serves two functions: accessing struct fields and accessing namespace declarations. This is the reason it needs to be renamed.

@fieldParentPtr is clearly performing its function; it only applies to fields.

@gschwind I don't think so. The current `@field` serves two functions: accessing struct fields and accessing namespace declarations. This is the reason it needs to be renamed. `@fieldParentPtr` is clearly performing its function; it only applies to fields.

gschwind commented

2026年05月10日 20:46:52 +02:00

Copy link

@npc1054657282 ok look good

anordinaryuser referenced this issue

2026年05月16日 03:35:28 +02:00

@FieldType() differs semantically from @TypeOf(@field()) #35323

nektro referenced this issue

2026年05月16日 03:43:51 +02:00

@FieldType() differs semantically from @TypeOf(@field()) #35323

eamonburns commented

2026年06月02日 19:27:10 +02:00

Copy link

Related: #30107

Related: https://codeberg.org/ziglang/zig/issues/30107

K4 commented

2026年06月02日 20:26:51 +02:00

Contributor

Copy link

I would like to work on this, but I need to update zig1.wasm right? I cannot do that because I have a 4GB machine. Would a series of patches that change uses of @field and @FieldType to @member and @Member still be useful?

I would like to work on this, but I need to update `zig1.wasm` right? I cannot do that because I have a 4GB machine. Would a series of patches that change uses of `@field` and `@FieldType` to `@member` and `@Member` still be useful?

No Branch/Tag specified

Branches Tags

master

elfv2

spork8

restricted

0.16.x

panic-rewrite

parking-futex-lockfree

windows-Io-cleanup

Io-watch

ParseCommandLineOptions

windows-async-files

poll-ring

debug-file-leaks-differently

debug-file-leaks

ProcessPrng

elfv2-dyn

jobserver

threadtheft

io-threaded-no-queue

0.15.x

Io.net

comptime-allocator

restricted-function-pointers

cli

wasm-linker-writer

wrangle-writer-buffering

sha1-stream

async-await-demo

fixes

0.14.x

ast-node-methods

macos-debug-info

make-vs-configure

fuzz-macos

sans-aro

ArrayList-reserve

incr-bug

llvm-ir-nosanitize-metadata

ci-tarballs

ci-scripts

threadpool

0.12.x

new-pkg-hash

json-diagnostics

more-doctests

rework-comptime-mutation

0.11.x

ci-perf-comment

stage2-async

0.10.x

autofix

0.9.x

aro

hcs

0.8.x

0.7.x

Labels

Clear labels

This proposal is planned.

The web application for interactive documentation and generation of its assets.

backend/c

The C backend outputs C source code.

backend/llvm

The LLVM backend outputs an LLVM bitcode module.

backend/self-hosted

The self-hosted backends produce machine code directly.

binutils

Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.

breaking

Implementing this issue could cause existing code to no longer compile or have different behavior.

build system

The Zig build system - zig build, std.Build, the build runner, and package management.

debug info

docs

An issue with documentation, e.g. the language reference or standard library doc comments.

error message

This issue points out an error message that is unhelpful and should be improved.

frontend

Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.

fuzzing

incremental

Reuse of internal compiler state for faster compilation.

lib/c

This issue relates to Zig's libc implementation and/or vendored libcs.

lib/compiler-rt

This issue relates to Zig's compiler-rt library.

lib/cxx

This issue relates to Zig's vendored libc++ and/or libc++abi.

lib/std

This issue relates to Zig's standard library.

lib/tsan

This issue relates to Zig's vendored libtsan.

lib/ubsan-rt

This issue relates to Zig's ubsan-rt library.

lib/unwind

This issue relates to Zig's vendored libunwind.

linking

Zig's integrated object file and incremental linker.

miscompilation

The compiler reports success but produces semantically incorrect code.

This issue suggests language modifications. If it also has the "accepted" label then it is planned.

release notes

This issue or pull request should be mentioned in the release notes.

testing

This issue is related to testing the compiler, standard library, or other parts of Zig.

zig cc

Zig as a drop-in C-family compiler.

zig fmt

The Zig source code formatter.

zig reduce

The Zig source code reduction tool.

bounty

https://ziglang.org/news/announcing-donor-bounties

bug

Observed behavior contradicts documented or intended behavior.

contributor-friendly

This issue is limited in scope and/or knowledge of project internals.

downstream

An issue with a third-party project that uses this project.

enhancement

Solving this issue will likely involve adding new logic or components to the codebase.

infra

optimization

A task to improve performance and/or resource usage.

question

No questions on the issue tracker; use a community space instead.

regression

Something that used to work in a previous version stopped working

upstream

An issue with a third-party project that this project uses.

use case

Describes a real use case that is difficult or impossible, but does not propose a solution.

No labels

Milestone

Clear milestone

No items

No milestone

Urgent

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

8 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ziglang/zig#32029

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?

rename @field to @member for clarity #32029

rename `@field` to `@member` for clarity #32029