In Go, what does the compiler do with a struct field tag like schema:"user_id"?

## Where a tag lives in the grammar A struct field declaration is a list of names, a type, and then optionally a **tag**: ```go type Field struct { Name string `schema:"name" doc:"column name"` Kind string `schema:"kind"` } ``` The tag is an ordinary string literal. It is not a comment, not a directive, and not a declaration of anything. The compiler's only requirement is that it parse as a string literal; the bytes inside it are never inspected. Write `"anything at all"` there and the program still builds. Because the tag follows the whole field declaration, a tag on a multi-name declaration applies to every name in it: ```go type Point struct { X, Y int `schema:"coord"` // one tag, both fields carry it } ``` An embedded field can carry a tag too, and so can an unexported field — the compiler does not care, even though most libraries that read tags will only ever look at exported fields. ## Why back quotes The conventional grammar puts the value in double quotes, so writing the tag as a back-quoted **raw string literal** lets you type `schema:"user_id"` verbatim. An interpreted (double-quoted) literal is legal too, but then every inner quote needs a backslash, which nobody wants to read. The back quote is convention plus convenience, not a special syntax for tags. ## The conventional format Nothing in the language defines a structure for the tag string — the format is a convention that the standard library and essentially every third-party library follow: - one or more pairs, separated by **single spaces**; - each pair is `key:"value"`, with **no space after the colon**; - the key is a short package-ish name identifying the library that owns it; - the value is a string whose internal structure (commonly a name followed by comma-separated options) is that library's business. A lookup for a key that is not present simply returns nothing, and the library falls back to whatever its default is — usually the field's own name. Two libraries never collide, because each looks only for its own key. The keys are not registered anywhere the toolchain can see; they are a community convention. ## Tags and type identity This catches people out. Two struct types are identical only if they have the same field names, identical field types **and identical tags**. So: ```go type A struct{ N int `k:"1"` } type B struct{ N int `k:"2"` } ``` `A` and `B` are different types, and a value of one is not assignable to the other. Go does, however, allow an **explicit conversion** between struct types whose fields match apart from their tags — which is precisely how a wire-shaped struct with transport tags is converted into a bare domain struct of the same shape without copying field by field. Tags also become part of the identity of anonymous struct types, so an anonymous struct used as a temporary decoding target must carry the same tags as anything you plan to convert it to. ## Who reads a tag Only run-time type inspection can retrieve a tag: the reflect package exposes the tag string attached to a field and a helper that pulls a single key's value out of it, and that is the whole mechanism. There is no compile-time reflection in Go, no macro that could act on a tag, and no code generation built into the language. That is why tag-driven libraries pay a run-time cost the first time they inspect a type, and why many of them cache the derived plan per type. This also explains the ceiling on what tags can do. They can express **data about a field** — a wire name, a validation rule, a column — and they cannot express behaviour, because a string cannot hold code. Anything richer belongs in a method or in generated code. ## Practical consequences - **Tags are unchecked, so typos are silent.** Nothing rejects `schemaa:"user_id"`. The build is green and the field is quietly invisible to the library. - **Tags are part of your API when the struct is exported.** Changing a tag value on a struct that some other system decodes is a contract change dressed up as a one-word edit. - **Tags are visible in the binary.** They are type information, not comments, so they are not stripped and can be read by anything with the type. - **Tags do not compose.** Embedding a type does not merge its tags into the outer struct's own fields; the embedded field keeps its own. The mental model to leave with: a struct tag is a note pinned to a field, written in a format nothing enforces, addressed to a reader who may or may not turn up at run time.