From cc1d7afb247677fd9a1f75d11587af00d65e231d Mon Sep 17 00:00:00 2001 From: Robert Griesemer Date: Tue, 6 Jan 2026 17:43:56 -0800 Subject: [PATCH] spec: slightly re-arrange composite literal section for readability - introduce subtitles to make various sub-sections easier to find - split rules for struct literals into two groups (literals without and with keys) - move section on syntax ambiguity up as it pertains to the syntax introduced at the start - move prose specific to map literals into its own section No language changes. Change-Id: If8895b869138693179ca6e4d8b1c6ebdc705eccf Reviewed-on: https://go-review.googlesource.com/c/go/+/734322 Reviewed-by: Alan Donovan Auto-Submit: Robert Griesemer LUCI-TryBot-Result: Go LUCI Reviewed-by: Robert Griesemer --- doc/go_spec.html | 95 ++++++++++++++++++++++++++++-------------------- 1 file changed, 55 insertions(+), 40 deletions(-) diff --git a/doc/go_spec.html b/doc/go_spec.html index f47f5a6e3e2..478aefd4a6f 100644 --- a/doc/go_spec.html +++ b/doc/go_spec.html @@ -1,6 +1,6 @@ @@ -3143,7 +3143,8 @@ math.Sin // denotes the Sin function in package math

Composite literals construct new values for structs, arrays, slices, and maps each time they are evaluated. -They consist of the type of the literal followed by a brace-bound list of elements. +They consist of the type of the literal followed by a (possibly empty) +brace-bound list of elements. Each element may optionally be preceded by a corresponding key.

@@ -3168,35 +3169,53 @@ as a TypeName). If the LiteralType is a type parameter, all types in its type set must have the same underlying type which must be a valid composite literal type. -The types of the elements and keys must be assignable -to the respective field, element, and key types of type T; -there is no additional conversion. -The key is interpreted as a field name for struct literals, -an index for array and slice literals, and a key for map literals. -For map literals, all elements must have a key. It is an error -to specify multiple elements with the same field name or -constant key value. For non-constant map keys, see the section on -evaluation order.

-For struct literals the following rules apply: +The types of the elements and keys must be assignable +to the respective field, element, and key types of the LiteralType; +there is no additional conversion. +The key is interpreted as a field name for struct literals, +an index for array and slice literals, and a key for map literals. +It is an error to specify multiple elements with the same field name +or constant key value. +A literal may omit the element list; such a literal evaluates +to the zero value for its type. +

+ +

+A parsing ambiguity arises when a composite literal using the +TypeName form of the LiteralType appears as an operand between the +keyword and the opening brace of the block +of an "if", "for", or "switch" statement, and the composite literal +is not enclosed in parentheses, square brackets, or curly braces. +In this rare case, the opening brace of the literal is erroneously parsed +as the one introducing the block of statements. To resolve the ambiguity, +the composite literal must appear within parentheses. +

+ +
+if x == (T{a,b,c}[i]) { … }
+if (x == T{a,b,c}[i]) { … }
+
+ +

Struct literals

+ +

+For struct literals without keys, the element list must contain an element +for each struct field in the order in which the fields are declared. +

+ +

+For struct literals with keys the following rules apply:

    -
  • A key must be a field name declared in the struct type. +
  • Every element must have a key.
    • -
  • An element list that does not contain any keys must - list an element for each struct field in the - order in which the fields are declared. +
  • Each key must be a field name declared in the struct type.
    • -
  • If any element has a key, every element must have a key. -
    • -
  • An element list that contains keys does not need to - have an element for each struct field. Omitted fields - get the zero value for that field. -
    • -
  • A literal may omit the element list; such a literal evaluates - to the zero value for its type. +
  • The element list does not need to have an element for each struct field. + Omitted fields get the zero value for that field.
  • It is an error to specify an element for a non-exported field of a struct belonging to a different package. @@ -3220,6 +3239,8 @@ origin := Point3D{} // zero value for Point3D line := Line{origin, Point3D{y: -4, z: 12.3}} // zero value for line.q.x +

    Array and slice literals

    +

    For array and slice literals the following rules apply:

    @@ -3295,6 +3316,16 @@ tmp := [n]T{x1, x2, … xn} tmp[0 : n] +

    Map literals

    + +

    +For map literals, each element must have a key. +For non-constant map keys, see the section on +evaluation order. +

    + +

    Elision of element types

    +

    Within a composite literal of array, slice, or map type T, elements or map keys that are themselves composite literals may elide the respective @@ -3315,22 +3346,6 @@ type PPoint *Point [2]PPoint{{1.5, -3.5}, {}} // same as [2]PPoint{PPoint(&Point{1.5, -3.5}), PPoint(&Point{})} -

    -A parsing ambiguity arises when a composite literal using the -TypeName form of the LiteralType appears as an operand between the -keyword and the opening brace of the block -of an "if", "for", or "switch" statement, and the composite literal -is not enclosed in parentheses, square brackets, or curly braces. -In this rare case, the opening brace of the literal is erroneously parsed -as the one introducing the block of statements. To resolve the ambiguity, -the composite literal must appear within parentheses. -

    - -
    -if x == (T{a,b,c}[i]) { … }
-if (x == T{a,b,c}[i]) { … }
-
    -

    Examples of valid array, slice, and map literals: