Embedded struct fields

March 13, 2023

When I introduced structs last week, I skipped over one sentence. Today I’m going to address that.

Struct types

A struct is a sequence of named elements, called fields, each of which has a name and a type. Field names may be specified explicitly (IdentifierList) or implicitly (EmbeddedField). Within a struct, non-blank field names must be unique.

We already saw how field names are expressed explicitly. But what is an embedded field? Well, I’m glad you asked. Because the next sentence in the spec tells us, followed by some examples:

A field declared with a type but no explicit field name is called an embedded field. An embedded field must be specified as a type name T or as a pointer to a non-interface type name *T, and T itself may not be a pointer type. The unqualified type name acts as the field name.

// A struct with four embedded fields of types T1, *T2, P.T3 and *P.T4
struct {
	T1        // field name is T1
	*T2       // field name is T2
	P.T3      // field name is T3
	*P.T4     // field name is T4
	x, y int  // field names are x and y

You may be wondering why we would ever use embedded struct fields, and the short answer is that this is one way Go gives us to accomplish composition. And we’ll talk more about methods on embedded types later. For now, let’s just consider how embedding can be useful for data.

type Person struct {
	Name string
	Age  int

type Employee struct {
	StartDate time.Time

In this very example, the Employee type embeds the Person type. This is roughly (though not exactly) the same as:

type Employee struct {
	Person    Person
	StartDate time.Time

By embedding the Person type within the Employee type, we’re effectively establishing a “has a” relationship. In other words, Employee has a Person.

And as a final note, the uniqueness constraint on field names is still enforced on embedded field names:

The following declaration is illegal because field names must be unique in a struct type:

struct {
	T     // conflicts with embedded field *T and *P.T
	*T    // conflicts with embedded field T and *P.T
	*P.T  // conflicts with embedded field T and *T

Quotes from The Go Programming Language Specification Version of December 15, 2022

Share this

Related Content

Struct tags

Struct types … A field declaration may be followed by an optional string literal tag, which becomes an attribute for all the fields in the corresponding field declaration. An empty tag string is equivalent to an absent tag. The tags are made visible through a reflection interface and take part in type identity for structs but are otherwise ignored. struct { x, y float64 "" // an empty tag string is like an absent tag name string "any string is permitted as a tag" _ [4]byte "ceci n'est pas un champ de structure" } // A struct corresponding to a TimeStamp protocol buffer.

Struct field promotion

Yesterday we learned that structs can have embedded fields. Although we didn’t really learn about any of the special powers this gives us. Today we’ll have a look at those powers. One advantage to using an embedded type is that the implicit field name (the one derrived from the type, Person, in our example) can be omitted. This is the result of “promotion”. For example: var e Employee e.Name = "Bob" // equivalent to e.

Blank field names

Yesterday we started talking about Go’s structs, and breezed over a phrase about non-blank field names. Wassat? Struct types … Within a struct, non-blank field names must be unique. Go has a concept of a blank identifier. It looks like the underscore character (_), and is useful in many situations, and we’ll discuss more of them in due time. (It’s also decidedly not useful in some situations where it’s permitted, and I made a video about that a while ago)