]> Cypherpunks.ru repositories - gostls13.git/blob - doc/go_spec.html
spec: add section on comparable constraint
[gostls13.git] / doc / go_spec.html
1 <!--{
2         "Title": "The Go Programming Language Specification - Go 1.18 Draft (incomplete)",
3         "Subtitle": "Version of Jan 31, 2022",
4         "Path": "/ref/spec"
5 }-->
6
7 <h2>Earlier version</h2>
8
9 <p>
10 For the pre-Go1.18 specification without generics support see
11 <a href="/doc/go1.17_spec.html">The Go Programming Language Specification</a>.
12 </p>
13
14 <h2 id="Introduction">Introduction</h2>
15
16 <p>
17 This is a reference manual for the Go programming language. For
18 more information and other documents, see <a href="/">golang.org</a>.
19 </p>
20
21 <p>
22 Go is a general-purpose language designed with systems programming
23 in mind. It is strongly typed and garbage-collected and has explicit
24 support for concurrent programming.  Programs are constructed from
25 <i>packages</i>, whose properties allow efficient management of
26 dependencies.
27 </p>
28
29 <p>
30 The grammar is compact and simple to parse, allowing for easy analysis
31 by automatic tools such as integrated development environments.
32 </p>
33
34 <h2 id="Notation">Notation</h2>
35 <p>
36 The syntax is specified using Extended Backus-Naur Form (EBNF):
37 </p>
38
39 <pre class="grammar">
40 Production  = production_name "=" [ Expression ] "." .
41 Expression  = Alternative { "|" Alternative } .
42 Alternative = Term { Term } .
43 Term        = production_name | token [ "…" token ] | Group | Option | Repetition .
44 Group       = "(" Expression ")" .
45 Option      = "[" Expression "]" .
46 Repetition  = "{" Expression "}" .
47 </pre>
48
49 <p>
50 Productions are expressions constructed from terms and the following
51 operators, in increasing precedence:
52 </p>
53 <pre class="grammar">
54 |   alternation
55 ()  grouping
56 []  option (0 or 1 times)
57 {}  repetition (0 to n times)
58 </pre>
59
60 <p>
61 Lower-case production names are used to identify lexical tokens.
62 Non-terminals are in CamelCase. Lexical tokens are enclosed in
63 double quotes <code>""</code> or back quotes <code>``</code>.
64 </p>
65
66 <p>
67 The form <code>a … b</code> represents the set of characters from
68 <code>a</code> through <code>b</code> as alternatives. The horizontal
69 ellipsis <code>…</code> is also used elsewhere in the spec to informally denote various
70 enumerations or code snippets that are not further specified. The character <code>…</code>
71 (as opposed to the three characters <code>...</code>) is not a token of the Go
72 language.
73 </p>
74
75 <h2 id="Source_code_representation">Source code representation</h2>
76
77 <p>
78 Source code is Unicode text encoded in
79 <a href="https://en.wikipedia.org/wiki/UTF-8">UTF-8</a>. The text is not
80 canonicalized, so a single accented code point is distinct from the
81 same character constructed from combining an accent and a letter;
82 those are treated as two code points.  For simplicity, this document
83 will use the unqualified term <i>character</i> to refer to a Unicode code point
84 in the source text.
85 </p>
86 <p>
87 Each code point is distinct; for instance, upper and lower case letters
88 are different characters.
89 </p>
90 <p>
91 Implementation restriction: For compatibility with other tools, a
92 compiler may disallow the NUL character (U+0000) in the source text.
93 </p>
94 <p>
95 Implementation restriction: For compatibility with other tools, a
96 compiler may ignore a UTF-8-encoded byte order mark
97 (U+FEFF) if it is the first Unicode code point in the source text.
98 A byte order mark may be disallowed anywhere else in the source.
99 </p>
100
101 <h3 id="Characters">Characters</h3>
102
103 <p>
104 The following terms are used to denote specific Unicode character classes:
105 </p>
106 <pre class="ebnf">
107 newline        = /* the Unicode code point U+000A */ .
108 unicode_char   = /* an arbitrary Unicode code point except newline */ .
109 unicode_letter = /* a Unicode code point classified as "Letter" */ .
110 unicode_digit  = /* a Unicode code point classified as "Number, decimal digit" */ .
111 </pre>
112
113 <p>
114 In <a href="https://www.unicode.org/versions/Unicode8.0.0/">The Unicode Standard 8.0</a>,
115 Section 4.5 "General Category" defines a set of character categories.
116 Go treats all characters in any of the Letter categories Lu, Ll, Lt, Lm, or Lo
117 as Unicode letters, and those in the Number category Nd as Unicode digits.
118 </p>
119
120 <h3 id="Letters_and_digits">Letters and digits</h3>
121
122 <p>
123 The underscore character <code>_</code> (U+005F) is considered a letter.
124 </p>
125 <pre class="ebnf">
126 letter        = unicode_letter | "_" .
127 decimal_digit = "0" … "9" .
128 binary_digit  = "0" | "1" .
129 octal_digit   = "0" … "7" .
130 hex_digit     = "0" … "9" | "A" … "F" | "a" … "f" .
131 </pre>
132
133 <h2 id="Lexical_elements">Lexical elements</h2>
134
135 <h3 id="Comments">Comments</h3>
136
137 <p>
138 Comments serve as program documentation. There are two forms:
139 </p>
140
141 <ol>
142 <li>
143 <i>Line comments</i> start with the character sequence <code>//</code>
144 and stop at the end of the line.
145 </li>
146 <li>
147 <i>General comments</i> start with the character sequence <code>/*</code>
148 and stop with the first subsequent character sequence <code>*/</code>.
149 </li>
150 </ol>
151
152 <p>
153 A comment cannot start inside a <a href="#Rune_literals">rune</a> or
154 <a href="#String_literals">string literal</a>, or inside a comment.
155 A general comment containing no newlines acts like a space.
156 Any other comment acts like a newline.
157 </p>
158
159 <h3 id="Tokens">Tokens</h3>
160
161 <p>
162 Tokens form the vocabulary of the Go language.
163 There are four classes: <i>identifiers</i>, <i>keywords</i>, <i>operators
164 and punctuation</i>, and <i>literals</i>.  <i>White space</i>, formed from
165 spaces (U+0020), horizontal tabs (U+0009),
166 carriage returns (U+000D), and newlines (U+000A),
167 is ignored except as it separates tokens
168 that would otherwise combine into a single token. Also, a newline or end of file
169 may trigger the insertion of a <a href="#Semicolons">semicolon</a>.
170 While breaking the input into tokens,
171 the next token is the longest sequence of characters that form a
172 valid token.
173 </p>
174
175 <h3 id="Semicolons">Semicolons</h3>
176
177 <p>
178 The formal grammar uses semicolons <code>";"</code> as terminators in
179 a number of productions. Go programs may omit most of these semicolons
180 using the following two rules:
181 </p>
182
183 <ol>
184 <li>
185 When the input is broken into tokens, a semicolon is automatically inserted
186 into the token stream immediately after a line's final token if that token is
187 <ul>
188         <li>an
189             <a href="#Identifiers">identifier</a>
190         </li>
191
192         <li>an
193             <a href="#Integer_literals">integer</a>,
194             <a href="#Floating-point_literals">floating-point</a>,
195             <a href="#Imaginary_literals">imaginary</a>,
196             <a href="#Rune_literals">rune</a>, or
197             <a href="#String_literals">string</a> literal
198         </li>
199
200         <li>one of the <a href="#Keywords">keywords</a>
201             <code>break</code>,
202             <code>continue</code>,
203             <code>fallthrough</code>, or
204             <code>return</code>
205         </li>
206
207         <li>one of the <a href="#Operators_and_punctuation">operators and punctuation</a>
208             <code>++</code>,
209             <code>--</code>,
210             <code>)</code>,
211             <code>]</code>, or
212             <code>}</code>
213         </li>
214 </ul>
215 </li>
216
217 <li>
218 To allow complex statements to occupy a single line, a semicolon
219 may be omitted before a closing <code>")"</code> or <code>"}"</code>.
220 </li>
221 </ol>
222
223 <p>
224 To reflect idiomatic use, code examples in this document elide semicolons
225 using these rules.
226 </p>
227
228
229 <h3 id="Identifiers">Identifiers</h3>
230
231 <p>
232 Identifiers name program entities such as variables and types.
233 An identifier is a sequence of one or more letters and digits.
234 The first character in an identifier must be a letter.
235 </p>
236 <pre class="ebnf">
237 identifier = letter { letter | unicode_digit } .
238 </pre>
239 <pre>
240 a
241 _x9
242 ThisVariableIsExported
243 αβ
244 </pre>
245
246 <p>
247 Some identifiers are <a href="#Predeclared_identifiers">predeclared</a>.
248 </p>
249
250
251 <h3 id="Keywords">Keywords</h3>
252
253 <p>
254 The following keywords are reserved and may not be used as identifiers.
255 </p>
256 <pre class="grammar">
257 break        default      func         interface    select
258 case         defer        go           map          struct
259 chan         else         goto         package      switch
260 const        fallthrough  if           range        type
261 continue     for          import       return       var
262 </pre>
263
264 <h3 id="Operators_and_punctuation">Operators and punctuation</h3>
265
266 <p>
267 The following character sequences represent <a href="#Operators">operators</a>
268 (including <a href="#Assignments">assignment operators</a>) and punctuation:
269 </p>
270 <pre class="grammar">
271 +    &amp;     +=    &amp;=     &amp;&amp;    ==    !=    (    )
272 -    |     -=    |=     ||    &lt;     &lt;=    [    ]
273 *    ^     *=    ^=     &lt;-    &gt;     &gt;=    {    }
274 /    &lt;&lt;    /=    &lt;&lt;=    ++    =     :=    ,    ;
275 %    &gt;&gt;    %=    &gt;&gt;=    --    !     ...   .    :
276      &amp;^          &amp;^=          ~
277 </pre>
278
279 <h3 id="Integer_literals">Integer literals</h3>
280
281 <p>
282 An integer literal is a sequence of digits representing an
283 <a href="#Constants">integer constant</a>.
284 An optional prefix sets a non-decimal base: <code>0b</code> or <code>0B</code>
285 for binary, <code>0</code>, <code>0o</code>, or <code>0O</code> for octal,
286 and <code>0x</code> or <code>0X</code> for hexadecimal.
287 A single <code>0</code> is considered a decimal zero.
288 In hexadecimal literals, letters <code>a</code> through <code>f</code>
289 and <code>A</code> through <code>F</code> represent values 10 through 15.
290 </p>
291
292 <p>
293 For readability, an underscore character <code>_</code> may appear after
294 a base prefix or between successive digits; such underscores do not change
295 the literal's value.
296 </p>
297 <pre class="ebnf">
298 int_lit        = decimal_lit | binary_lit | octal_lit | hex_lit .
299 decimal_lit    = "0" | ( "1" … "9" ) [ [ "_" ] decimal_digits ] .
300 binary_lit     = "0" ( "b" | "B" ) [ "_" ] binary_digits .
301 octal_lit      = "0" [ "o" | "O" ] [ "_" ] octal_digits .
302 hex_lit        = "0" ( "x" | "X" ) [ "_" ] hex_digits .
303
304 decimal_digits = decimal_digit { [ "_" ] decimal_digit } .
305 binary_digits  = binary_digit { [ "_" ] binary_digit } .
306 octal_digits   = octal_digit { [ "_" ] octal_digit } .
307 hex_digits     = hex_digit { [ "_" ] hex_digit } .
308 </pre>
309
310 <pre>
311 42
312 4_2
313 0600
314 0_600
315 0o600
316 0O600       // second character is capital letter 'O'
317 0xBadFace
318 0xBad_Face
319 0x_67_7a_2f_cc_40_c6
320 170141183460469231731687303715884105727
321 170_141183_460469_231731_687303_715884_105727
322
323 _42         // an identifier, not an integer literal
324 42_         // invalid: _ must separate successive digits
325 4__2        // invalid: only one _ at a time
326 0_xBadFace  // invalid: _ must separate successive digits
327 </pre>
328
329
330 <h3 id="Floating-point_literals">Floating-point literals</h3>
331
332 <p>
333 A floating-point literal is a decimal or hexadecimal representation of a
334 <a href="#Constants">floating-point constant</a>.
335 </p>
336
337 <p>
338 A decimal floating-point literal consists of an integer part (decimal digits),
339 a decimal point, a fractional part (decimal digits), and an exponent part
340 (<code>e</code> or <code>E</code> followed by an optional sign and decimal digits).
341 One of the integer part or the fractional part may be elided; one of the decimal point
342 or the exponent part may be elided.
343 An exponent value exp scales the mantissa (integer and fractional part) by 10<sup>exp</sup>.
344 </p>
345
346 <p>
347 A hexadecimal floating-point literal consists of a <code>0x</code> or <code>0X</code>
348 prefix, an integer part (hexadecimal digits), a radix point, a fractional part (hexadecimal digits),
349 and an exponent part (<code>p</code> or <code>P</code> followed by an optional sign and decimal digits).
350 One of the integer part or the fractional part may be elided; the radix point may be elided as well,
351 but the exponent part is required. (This syntax matches the one given in IEEE 754-2008 §5.12.3.)
352 An exponent value exp scales the mantissa (integer and fractional part) by 2<sup>exp</sup>.
353 </p>
354
355 <p>
356 For readability, an underscore character <code>_</code> may appear after
357 a base prefix or between successive digits; such underscores do not change
358 the literal value.
359 </p>
360
361 <pre class="ebnf">
362 float_lit         = decimal_float_lit | hex_float_lit .
363
364 decimal_float_lit = decimal_digits "." [ decimal_digits ] [ decimal_exponent ] |
365                     decimal_digits decimal_exponent |
366                     "." decimal_digits [ decimal_exponent ] .
367 decimal_exponent  = ( "e" | "E" ) [ "+" | "-" ] decimal_digits .
368
369 hex_float_lit     = "0" ( "x" | "X" ) hex_mantissa hex_exponent .
370 hex_mantissa      = [ "_" ] hex_digits "." [ hex_digits ] |
371                     [ "_" ] hex_digits |
372                     "." hex_digits .
373 hex_exponent      = ( "p" | "P" ) [ "+" | "-" ] decimal_digits .
374 </pre>
375
376 <pre>
377 0.
378 72.40
379 072.40       // == 72.40
380 2.71828
381 1.e+0
382 6.67428e-11
383 1E6
384 .25
385 .12345E+5
386 1_5.         // == 15.0
387 0.15e+0_2    // == 15.0
388
389 0x1p-2       // == 0.25
390 0x2.p10      // == 2048.0
391 0x1.Fp+0     // == 1.9375
392 0X.8p-0      // == 0.5
393 0X_1FFFP-16  // == 0.1249847412109375
394 0x15e-2      // == 0x15e - 2 (integer subtraction)
395
396 0x.p1        // invalid: mantissa has no digits
397 1p-2         // invalid: p exponent requires hexadecimal mantissa
398 0x1.5e-2     // invalid: hexadecimal mantissa requires p exponent
399 1_.5         // invalid: _ must separate successive digits
400 1._5         // invalid: _ must separate successive digits
401 1.5_e1       // invalid: _ must separate successive digits
402 1.5e_1       // invalid: _ must separate successive digits
403 1.5e1_       // invalid: _ must separate successive digits
404 </pre>
405
406
407 <h3 id="Imaginary_literals">Imaginary literals</h3>
408
409 <p>
410 An imaginary literal represents the imaginary part of a
411 <a href="#Constants">complex constant</a>.
412 It consists of an <a href="#Integer_literals">integer</a> or
413 <a href="#Floating-point_literals">floating-point</a> literal
414 followed by the lower-case letter <code>i</code>.
415 The value of an imaginary literal is the value of the respective
416 integer or floating-point literal multiplied by the imaginary unit <i>i</i>.
417 </p>
418
419 <pre class="ebnf">
420 imaginary_lit = (decimal_digits | int_lit | float_lit) "i" .
421 </pre>
422
423 <p>
424 For backward compatibility, an imaginary literal's integer part consisting
425 entirely of decimal digits (and possibly underscores) is considered a decimal
426 integer, even if it starts with a leading <code>0</code>.
427 </p>
428
429 <pre>
430 0i
431 0123i         // == 123i for backward-compatibility
432 0o123i        // == 0o123 * 1i == 83i
433 0xabci        // == 0xabc * 1i == 2748i
434 0.i
435 2.71828i
436 1.e+0i
437 6.67428e-11i
438 1E6i
439 .25i
440 .12345E+5i
441 0x1p-2i       // == 0x1p-2 * 1i == 0.25i
442 </pre>
443
444
445 <h3 id="Rune_literals">Rune literals</h3>
446
447 <p>
448 A rune literal represents a <a href="#Constants">rune constant</a>,
449 an integer value identifying a Unicode code point.
450 A rune literal is expressed as one or more characters enclosed in single quotes,
451 as in <code>'x'</code> or <code>'\n'</code>.
452 Within the quotes, any character may appear except newline and unescaped single
453 quote. A single quoted character represents the Unicode value
454 of the character itself,
455 while multi-character sequences beginning with a backslash encode
456 values in various formats.
457 </p>
458
459 <p>
460 The simplest form represents the single character within the quotes;
461 since Go source text is Unicode characters encoded in UTF-8, multiple
462 UTF-8-encoded bytes may represent a single integer value.  For
463 instance, the literal <code>'a'</code> holds a single byte representing
464 a literal <code>a</code>, Unicode U+0061, value <code>0x61</code>, while
465 <code>'ä'</code> holds two bytes (<code>0xc3</code> <code>0xa4</code>) representing
466 a literal <code>a</code>-dieresis, U+00E4, value <code>0xe4</code>.
467 </p>
468
469 <p>
470 Several backslash escapes allow arbitrary values to be encoded as
471 ASCII text.  There are four ways to represent the integer value
472 as a numeric constant: <code>\x</code> followed by exactly two hexadecimal
473 digits; <code>\u</code> followed by exactly four hexadecimal digits;
474 <code>\U</code> followed by exactly eight hexadecimal digits, and a
475 plain backslash <code>\</code> followed by exactly three octal digits.
476 In each case the value of the literal is the value represented by
477 the digits in the corresponding base.
478 </p>
479
480 <p>
481 Although these representations all result in an integer, they have
482 different valid ranges.  Octal escapes must represent a value between
483 0 and 255 inclusive.  Hexadecimal escapes satisfy this condition
484 by construction. The escapes <code>\u</code> and <code>\U</code>
485 represent Unicode code points so within them some values are illegal,
486 in particular those above <code>0x10FFFF</code> and surrogate halves.
487 </p>
488
489 <p>
490 After a backslash, certain single-character escapes represent special values:
491 </p>
492
493 <pre class="grammar">
494 \a   U+0007 alert or bell
495 \b   U+0008 backspace
496 \f   U+000C form feed
497 \n   U+000A line feed or newline
498 \r   U+000D carriage return
499 \t   U+0009 horizontal tab
500 \v   U+000B vertical tab
501 \\   U+005C backslash
502 \'   U+0027 single quote  (valid escape only within rune literals)
503 \"   U+0022 double quote  (valid escape only within string literals)
504 </pre>
505
506 <p>
507 All other sequences starting with a backslash are illegal inside rune literals.
508 </p>
509 <pre class="ebnf">
510 rune_lit         = "'" ( unicode_value | byte_value ) "'" .
511 unicode_value    = unicode_char | little_u_value | big_u_value | escaped_char .
512 byte_value       = octal_byte_value | hex_byte_value .
513 octal_byte_value = `\` octal_digit octal_digit octal_digit .
514 hex_byte_value   = `\` "x" hex_digit hex_digit .
515 little_u_value   = `\` "u" hex_digit hex_digit hex_digit hex_digit .
516 big_u_value      = `\` "U" hex_digit hex_digit hex_digit hex_digit
517                            hex_digit hex_digit hex_digit hex_digit .
518 escaped_char     = `\` ( "a" | "b" | "f" | "n" | "r" | "t" | "v" | `\` | "'" | `"` ) .
519 </pre>
520
521 <pre>
522 'a'
523 'ä'
524 '本'
525 '\t'
526 '\000'
527 '\007'
528 '\377'
529 '\x07'
530 '\xff'
531 '\u12e4'
532 '\U00101234'
533 '\''         // rune literal containing single quote character
534 'aa'         // illegal: too many characters
535 '\xa'        // illegal: too few hexadecimal digits
536 '\0'         // illegal: too few octal digits
537 '\uDFFF'     // illegal: surrogate half
538 '\U00110000' // illegal: invalid Unicode code point
539 </pre>
540
541
542 <h3 id="String_literals">String literals</h3>
543
544 <p>
545 A string literal represents a <a href="#Constants">string constant</a>
546 obtained from concatenating a sequence of characters. There are two forms:
547 raw string literals and interpreted string literals.
548 </p>
549
550 <p>
551 Raw string literals are character sequences between back quotes, as in
552 <code>`foo`</code>.  Within the quotes, any character may appear except
553 back quote. The value of a raw string literal is the
554 string composed of the uninterpreted (implicitly UTF-8-encoded) characters
555 between the quotes;
556 in particular, backslashes have no special meaning and the string may
557 contain newlines.
558 Carriage return characters ('\r') inside raw string literals
559 are discarded from the raw string value.
560 </p>
561
562 <p>
563 Interpreted string literals are character sequences between double
564 quotes, as in <code>&quot;bar&quot;</code>.
565 Within the quotes, any character may appear except newline and unescaped double quote.
566 The text between the quotes forms the
567 value of the literal, with backslash escapes interpreted as they
568 are in <a href="#Rune_literals">rune literals</a> (except that <code>\'</code> is illegal and
569 <code>\"</code> is legal), with the same restrictions.
570 The three-digit octal (<code>\</code><i>nnn</i>)
571 and two-digit hexadecimal (<code>\x</code><i>nn</i>) escapes represent individual
572 <i>bytes</i> of the resulting string; all other escapes represent
573 the (possibly multi-byte) UTF-8 encoding of individual <i>characters</i>.
574 Thus inside a string literal <code>\377</code> and <code>\xFF</code> represent
575 a single byte of value <code>0xFF</code>=255, while <code>ÿ</code>,
576 <code>\u00FF</code>, <code>\U000000FF</code> and <code>\xc3\xbf</code> represent
577 the two bytes <code>0xc3</code> <code>0xbf</code> of the UTF-8 encoding of character
578 U+00FF.
579 </p>
580
581 <pre class="ebnf">
582 string_lit             = raw_string_lit | interpreted_string_lit .
583 raw_string_lit         = "`" { unicode_char | newline } "`" .
584 interpreted_string_lit = `"` { unicode_value | byte_value } `"` .
585 </pre>
586
587 <pre>
588 `abc`                // same as "abc"
589 `\n
590 \n`                  // same as "\\n\n\\n"
591 "\n"
592 "\""                 // same as `"`
593 "Hello, world!\n"
594 "日本語"
595 "\u65e5本\U00008a9e"
596 "\xff\u00FF"
597 "\uD800"             // illegal: surrogate half
598 "\U00110000"         // illegal: invalid Unicode code point
599 </pre>
600
601 <p>
602 These examples all represent the same string:
603 </p>
604
605 <pre>
606 "日本語"                                 // UTF-8 input text
607 `日本語`                                 // UTF-8 input text as a raw literal
608 "\u65e5\u672c\u8a9e"                    // the explicit Unicode code points
609 "\U000065e5\U0000672c\U00008a9e"        // the explicit Unicode code points
610 "\xe6\x97\xa5\xe6\x9c\xac\xe8\xaa\x9e"  // the explicit UTF-8 bytes
611 </pre>
612
613 <p>
614 If the source code represents a character as two code points, such as
615 a combining form involving an accent and a letter, the result will be
616 an error if placed in a rune literal (it is not a single code
617 point), and will appear as two code points if placed in a string
618 literal.
619 </p>
620
621
622 <h2 id="Constants">Constants</h2>
623
624 <p>There are <i>boolean constants</i>,
625 <i>rune constants</i>,
626 <i>integer constants</i>,
627 <i>floating-point constants</i>, <i>complex constants</i>,
628 and <i>string constants</i>. Rune, integer, floating-point,
629 and complex constants are
630 collectively called <i>numeric constants</i>.
631 </p>
632
633 <p>
634 A constant value is represented by a
635 <a href="#Rune_literals">rune</a>,
636 <a href="#Integer_literals">integer</a>,
637 <a href="#Floating-point_literals">floating-point</a>,
638 <a href="#Imaginary_literals">imaginary</a>,
639 or
640 <a href="#String_literals">string</a> literal,
641 an identifier denoting a constant,
642 a <a href="#Constant_expressions">constant expression</a>,
643 a <a href="#Conversions">conversion</a> with a result that is a constant, or
644 the result value of some built-in functions such as
645 <code>unsafe.Sizeof</code> applied to <a href="#Package_unsafe">certain values</a>,
646 <code>cap</code> or <code>len</code> applied to
647 <a href="#Length_and_capacity">some expressions</a>,
648 <code>real</code> and <code>imag</code> applied to a complex constant
649 and <code>complex</code> applied to numeric constants.
650 The boolean truth values are represented by the predeclared constants
651 <code>true</code> and <code>false</code>. The predeclared identifier
652 <a href="#Iota">iota</a> denotes an integer constant.
653 </p>
654
655 <p>
656 In general, complex constants are a form of
657 <a href="#Constant_expressions">constant expression</a>
658 and are discussed in that section.
659 </p>
660
661 <p>
662 Numeric constants represent exact values of arbitrary precision and do not overflow.
663 Consequently, there are no constants denoting the IEEE-754 negative zero, infinity,
664 and not-a-number values.
665 </p>
666
667 <p>
668 Constants may be <a href="#Types">typed</a> or <i>untyped</i>.
669 Literal constants, <code>true</code>, <code>false</code>, <code>iota</code>,
670 and certain <a href="#Constant_expressions">constant expressions</a>
671 containing only untyped constant operands are untyped.
672 </p>
673
674 <p>
675 A constant may be given a type explicitly by a <a href="#Constant_declarations">constant declaration</a>
676 or <a href="#Conversions">conversion</a>, or implicitly when used in a
677 <a href="#Variable_declarations">variable declaration</a> or an
678 <a href="#Assignments">assignment</a> or as an
679 operand in an <a href="#Expressions">expression</a>.
680 It is an error if the constant value
681 cannot be <a href="#Representability">represented</a> as a value of the respective type.
682 </p>
683
684 <p>
685 An untyped constant has a <i>default type</i> which is the type to which the
686 constant is implicitly converted in contexts where a typed value is required,
687 for instance, in a <a href="#Short_variable_declarations">short variable declaration</a>
688 such as <code>i := 0</code> where there is no explicit type.
689 The default type of an untyped constant is <code>bool</code>, <code>rune</code>,
690 <code>int</code>, <code>float64</code>, <code>complex128</code> or <code>string</code>
691 respectively, depending on whether it is a boolean, rune, integer, floating-point,
692 complex, or string constant.
693 </p>
694
695 <p>
696 Implementation restriction: Although numeric constants have arbitrary
697 precision in the language, a compiler may implement them using an
698 internal representation with limited precision.  That said, every
699 implementation must:
700 </p>
701
702 <ul>
703         <li>Represent integer constants with at least 256 bits.</li>
704
705         <li>Represent floating-point constants, including the parts of
706             a complex constant, with a mantissa of at least 256 bits
707             and a signed binary exponent of at least 16 bits.</li>
708
709         <li>Give an error if unable to represent an integer constant
710             precisely.</li>
711
712         <li>Give an error if unable to represent a floating-point or
713             complex constant due to overflow.</li>
714
715         <li>Round to the nearest representable constant if unable to
716             represent a floating-point or complex constant due to limits
717             on precision.</li>
718 </ul>
719
720 <p>
721 These requirements apply both to literal constants and to the result
722 of evaluating <a href="#Constant_expressions">constant
723 expressions</a>.
724 </p>
725
726
727 <h2 id="Variables">Variables</h2>
728
729 <p>
730 A variable is a storage location for holding a <i>value</i>.
731 The set of permissible values is determined by the
732 variable's <i><a href="#Types">type</a></i>.
733 </p>
734
735 <p>
736 A <a href="#Variable_declarations">variable declaration</a>
737 or, for function parameters and results, the signature
738 of a <a href="#Function_declarations">function declaration</a>
739 or <a href="#Function_literals">function literal</a> reserves
740 storage for a named variable.
741
742 Calling the built-in function <a href="#Allocation"><code>new</code></a>
743 or taking the address of a <a href="#Composite_literals">composite literal</a>
744 allocates storage for a variable at run time.
745 Such an anonymous variable is referred to via a (possibly implicit)
746 <a href="#Address_operators">pointer indirection</a>.
747 </p>
748
749 <p>
750 <i>Structured</i> variables of <a href="#Array_types">array</a>, <a href="#Slice_types">slice</a>,
751 and <a href="#Struct_types">struct</a> types have elements and fields that may
752 be <a href="#Address_operators">addressed</a> individually. Each such element
753 acts like a variable.
754 </p>
755
756 <p>
757 The <i>static type</i> (or just <i>type</i>) of a variable is the
758 type given in its declaration, the type provided in the
759 <code>new</code> call or composite literal, or the type of
760 an element of a structured variable.
761 Variables of interface type also have a distinct <i>dynamic type</i>,
762 which is the concrete type of the value assigned to the variable at run time
763 (unless the value is the predeclared identifier <code>nil</code>,
764 which has no type).
765 The dynamic type may vary during execution but values stored in interface
766 variables are always <a href="#Assignability">assignable</a>
767 to the static type of the variable.
768 </p>
769
770 <pre>
771 var x interface{}  // x is nil and has static type interface{}
772 var v *T           // v has value nil, static type *T
773 x = 42             // x has value 42 and dynamic type int
774 x = v              // x has value (*T)(nil) and dynamic type *T
775 </pre>
776
777 <p>
778 A variable's value is retrieved by referring to the variable in an
779 <a href="#Expressions">expression</a>; it is the most recent value
780 <a href="#Assignments">assigned</a> to the variable.
781 If a variable has not yet been assigned a value, its value is the
782 <a href="#The_zero_value">zero value</a> for its type.
783 </p>
784
785
786 <h2 id="Types">Types</h2>
787
788 <p>
789 A type determines a set of values together with operations and methods specific
790 to those values. A type may be denoted by a <i>type name</i>, if it has one, which must be
791 followed by <a href="#Instantiations">type arguments</a> if the type is parameterized.
792 A type may also be specified using a <i>type literal</i>, which composes a type
793 from existing types.
794 </p>
795
796 <pre class="ebnf">
797 Type      = TypeName [ TypeArgs ] | TypeLit | "(" Type ")" .
798 TypeName  = identifier | QualifiedIdent .
799 TypeArgs  = "[" TypeList [ "," ] "]" .
800 TypeList  = Type { "," Type } .
801 TypeLit   = ArrayType | StructType | PointerType | FunctionType | InterfaceType |
802             SliceType | MapType | ChannelType .
803 </pre>
804
805 <p>
806 The language <a href="#Predeclared_identifiers">predeclares</a> certain type names.
807 Others are introduced with <a href="#Type_declarations">type declarations</a>
808 or <a href="#Type_parameter_lists">type parameter lists</a>.
809 <i>Composite types</i>&mdash;array, struct, pointer, function,
810 interface, slice, map, and channel types&mdash;may be constructed using
811 type literals.
812 </p>
813
814 <p>
815 Predeclared types, defined types, and type parameters are called <i>named types</i>.
816 An alias denotes a named type if the type given in the alias declaration is a named type.
817 </p>
818
819 <h3 id="Underlying_types">Underlying types</h3>
820
821 <p>
822 Each type <code>T</code> has an <i>underlying type</i>: If <code>T</code>
823 is one of the predeclared boolean, numeric, or string types, or a type literal,
824 the corresponding underlying type is <code>T</code> itself.
825 Otherwise, <code>T</code>'s underlying type is the underlying type of the
826 type to which <code>T</code> refers in its <a href="#Type_declarations">type
827 declaration</a>. Accordingly, the underlying type of a type parameter is the
828 underlying type of its <a href="#Type_constraints">type constraint</a>, which
829 is always an interface.
830 </p>
831
832 <pre>
833 type (
834         A1 = string
835         A2 = A1
836 )
837
838 type (
839         B1 string
840         B2 B1
841         B3 []B1
842         B4 B3
843 )
844
845 func f[P any](x P) { … }
846 </pre>
847
848 <p>
849 The underlying type of <code>string</code>, <code>A1</code>, <code>A2</code>, <code>B1</code>,
850 and <code>B2</code> is <code>string</code>.
851 The underlying type of <code>[]B1</code>, <code>B3</code>, and <code>B4</code> is <code>[]B1</code>.
852 The underlying type of <code>P</code> is <code>interface{}</code>.
853 </p>
854
855 <h3 id="Method_sets">Method sets</h3>
856
857 <p>
858 The <i>method set</i> of a type determines the methods that can be
859 <a href="#Calls">called</a> on an <a href="#Operands">operand</a> of that type.
860 Every type has a (possibly empty) method set associated with it:
861 </p>
862
863 <ul>
864 <li>The method set of a <a href="#Type_definitions">defined type</a> <code>T</code> consists of all
865 <a href="#Method_declarations">methods</a> declared with receiver type <code>T</code>.
866 </li>
867
868 <li>
869 The method set of a pointer to a defined type <code>T</code>
870 (where <code>T</code> is neither a pointer nor an interface)
871 is the set of all methods declared with receiver <code>*T</code> or <code>T</code>.
872 </li>
873
874 <li>The method set of an <a href="#Interface_types">interface type</a> is the intersection
875 of the method sets of each type in the interface's <a href="#Interface_types">type set</a>
876 (the resulting method set is usually just the set of declared methods in the interface).
877 </li>
878 </ul>
879
880 <p>
881 Further rules apply to structs (and pointer to structs) containing embedded fields,
882 as described in the section on <a href="#Struct_types">struct types</a>.
883 Any other type has an empty method set.
884 </p>
885
886 <p>
887 In a method set, each method must have a
888 <a href="#Uniqueness_of_identifiers">unique</a>
889 non-<a href="#Blank_identifier">blank</a> <a href="#MethodName">method name</a>.
890 </p>
891
892 <h3 id="Boolean_types">Boolean types</h3>
893
894 <p>
895 A <i>boolean type</i> represents the set of Boolean truth values
896 denoted by the predeclared constants <code>true</code>
897 and <code>false</code>. The predeclared boolean type is <code>bool</code>;
898 it is a <a href="#Type_definitions">defined type</a>.
899 </p>
900
901 <h3 id="Numeric_types">Numeric types</h3>
902
903 <p>
904 A <i>numeric type</i> represents sets of integer or floating-point values.
905 The predeclared architecture-independent numeric types are:
906 </p>
907
908 <pre class="grammar">
909 uint8       the set of all unsigned  8-bit integers (0 to 255)
910 uint16      the set of all unsigned 16-bit integers (0 to 65535)
911 uint32      the set of all unsigned 32-bit integers (0 to 4294967295)
912 uint64      the set of all unsigned 64-bit integers (0 to 18446744073709551615)
913
914 int8        the set of all signed  8-bit integers (-128 to 127)
915 int16       the set of all signed 16-bit integers (-32768 to 32767)
916 int32       the set of all signed 32-bit integers (-2147483648 to 2147483647)
917 int64       the set of all signed 64-bit integers (-9223372036854775808 to 9223372036854775807)
918
919 float32     the set of all IEEE-754 32-bit floating-point numbers
920 float64     the set of all IEEE-754 64-bit floating-point numbers
921
922 complex64   the set of all complex numbers with float32 real and imaginary parts
923 complex128  the set of all complex numbers with float64 real and imaginary parts
924
925 byte        alias for uint8
926 rune        alias for int32
927 </pre>
928
929 <p>
930 The value of an <i>n</i>-bit integer is <i>n</i> bits wide and represented using
931 <a href="https://en.wikipedia.org/wiki/Two's_complement">two's complement arithmetic</a>.
932 </p>
933
934 <p>
935 There is also a set of predeclared numeric types with implementation-specific sizes:
936 </p>
937
938 <pre class="grammar">
939 uint     either 32 or 64 bits
940 int      same size as uint
941 uintptr  an unsigned integer large enough to store the uninterpreted bits of a pointer value
942 </pre>
943
944 <p>
945 To avoid portability issues all numeric types are <a href="#Type_definitions">defined
946 types</a> and thus distinct except
947 <code>byte</code>, which is an <a href="#Alias_declarations">alias</a> for <code>uint8</code>, and
948 <code>rune</code>, which is an alias for <code>int32</code>.
949 Explicit conversions
950 are required when different numeric types are mixed in an expression
951 or assignment. For instance, <code>int32</code> and <code>int</code>
952 are not the same type even though they may have the same size on a
953 particular architecture.
954
955
956 <h3 id="String_types">String types</h3>
957
958 <p>
959 A <i>string type</i> represents the set of string values.
960 A string value is a (possibly empty) sequence of bytes.
961 The number of bytes is called the length of the string and is never negative.
962 Strings are immutable: once created,
963 it is impossible to change the contents of a string.
964 The predeclared string type is <code>string</code>;
965 it is a <a href="#Type_definitions">defined type</a>.
966 </p>
967
968 <p>
969 The length of a string <code>s</code> can be discovered using
970 the built-in function <a href="#Length_and_capacity"><code>len</code></a>.
971 The length is a compile-time constant if the string is a constant.
972 A string's bytes can be accessed by integer <a href="#Index_expressions">indices</a>
973 0 through <code>len(s)-1</code>.
974 It is illegal to take the address of such an element; if
975 <code>s[i]</code> is the <code>i</code>'th byte of a
976 string, <code>&amp;s[i]</code> is invalid.
977 </p>
978
979
980 <h3 id="Array_types">Array types</h3>
981
982 <p>
983 An array is a numbered sequence of elements of a single
984 type, called the element type.
985 The number of elements is called the length of the array and is never negative.
986 </p>
987
988 <pre class="ebnf">
989 ArrayType   = "[" ArrayLength "]" ElementType .
990 ArrayLength = Expression .
991 ElementType = Type .
992 </pre>
993
994 <p>
995 The length is part of the array's type; it must evaluate to a
996 non-negative <a href="#Constants">constant</a>
997 <a href="#Representability">representable</a> by a value
998 of type <code>int</code>.
999 The length of array <code>a</code> can be discovered
1000 using the built-in function <a href="#Length_and_capacity"><code>len</code></a>.
1001 The elements can be addressed by integer <a href="#Index_expressions">indices</a>
1002 0 through <code>len(a)-1</code>.
1003 Array types are always one-dimensional but may be composed to form
1004 multi-dimensional types.
1005 </p>
1006
1007 <pre>
1008 [32]byte
1009 [2*N] struct { x, y int32 }
1010 [1000]*float64
1011 [3][5]int
1012 [2][2][2]float64  // same as [2]([2]([2]float64))
1013 </pre>
1014
1015 <h3 id="Slice_types">Slice types</h3>
1016
1017 <p>
1018 A slice is a descriptor for a contiguous segment of an <i>underlying array</i> and
1019 provides access to a numbered sequence of elements from that array.
1020 A slice type denotes the set of all slices of arrays of its element type.
1021 The number of elements is called the length of the slice and is never negative.
1022 The value of an uninitialized slice is <code>nil</code>.
1023 </p>
1024
1025 <pre class="ebnf">
1026 SliceType = "[" "]" ElementType .
1027 </pre>
1028
1029 <p>
1030 The length of a slice <code>s</code> can be discovered by the built-in function
1031 <a href="#Length_and_capacity"><code>len</code></a>; unlike with arrays it may change during
1032 execution.  The elements can be addressed by integer <a href="#Index_expressions">indices</a>
1033 0 through <code>len(s)-1</code>.  The slice index of a
1034 given element may be less than the index of the same element in the
1035 underlying array.
1036 </p>
1037 <p>
1038 A slice, once initialized, is always associated with an underlying
1039 array that holds its elements.  A slice therefore shares storage
1040 with its array and with other slices of the same array; by contrast,
1041 distinct arrays always represent distinct storage.
1042 </p>
1043 <p>
1044 The array underlying a slice may extend past the end of the slice.
1045 The <i>capacity</i> is a measure of that extent: it is the sum of
1046 the length of the slice and the length of the array beyond the slice;
1047 a slice of length up to that capacity can be created by
1048 <a href="#Slice_expressions"><i>slicing</i></a> a new one from the original slice.
1049 The capacity of a slice <code>a</code> can be discovered using the
1050 built-in function <a href="#Length_and_capacity"><code>cap(a)</code></a>.
1051 </p>
1052
1053 <p>
1054 A new, initialized slice value for a given element type <code>T</code> is
1055 made using the built-in function
1056 <a href="#Making_slices_maps_and_channels"><code>make</code></a>,
1057 which takes a slice type
1058 and parameters specifying the length and optionally the capacity.
1059 A slice created with <code>make</code> always allocates a new, hidden array
1060 to which the returned slice value refers. That is, executing
1061 </p>
1062
1063 <pre>
1064 make([]T, length, capacity)
1065 </pre>
1066
1067 <p>
1068 produces the same slice as allocating an array and <a href="#Slice_expressions">slicing</a>
1069 it, so these two expressions are equivalent:
1070 </p>
1071
1072 <pre>
1073 make([]int, 50, 100)
1074 new([100]int)[0:50]
1075 </pre>
1076
1077 <p>
1078 Like arrays, slices are always one-dimensional but may be composed to construct
1079 higher-dimensional objects.
1080 With arrays of arrays, the inner arrays are, by construction, always the same length;
1081 however with slices of slices (or arrays of slices), the inner lengths may vary dynamically.
1082 Moreover, the inner slices must be initialized individually.
1083 </p>
1084
1085 <h3 id="Struct_types">Struct types</h3>
1086
1087 <p>
1088 A struct is a sequence of named elements, called fields, each of which has a
1089 name and a type. Field names may be specified explicitly (IdentifierList) or
1090 implicitly (EmbeddedField).
1091 Within a struct, non-<a href="#Blank_identifier">blank</a> field names must
1092 be <a href="#Uniqueness_of_identifiers">unique</a>.
1093 </p>
1094
1095 <pre class="ebnf">
1096 StructType    = "struct" "{" { FieldDecl ";" } "}" .
1097 FieldDecl     = (IdentifierList Type | EmbeddedField) [ Tag ] .
1098 EmbeddedField = [ "*" ] TypeName .
1099 Tag           = string_lit .
1100 </pre>
1101
1102 <pre>
1103 // An empty struct.
1104 struct {}
1105
1106 // A struct with 6 fields.
1107 struct {
1108         x, y int
1109         u float32
1110         _ float32  // padding
1111         A *[]int
1112         F func()
1113 }
1114 </pre>
1115
1116 <p>
1117 A field declared with a type but no explicit field name is called an <i>embedded field</i>.
1118 An embedded field must be specified as
1119 a type name <code>T</code> or as a pointer to a non-interface type name <code>*T</code>,
1120 and <code>T</code> itself may not be
1121 a pointer type. The unqualified type name acts as the field name.
1122 </p>
1123
1124 <pre>
1125 // A struct with four embedded fields of types T1, *T2, P.T3 and *P.T4
1126 struct {
1127         T1        // field name is T1
1128         *T2       // field name is T2
1129         P.T3      // field name is T3
1130         *P.T4     // field name is T4
1131         x, y int  // field names are x and y
1132 }
1133 </pre>
1134
1135 <p>
1136 The following declaration is illegal because field names must be unique
1137 in a struct type:
1138 </p>
1139
1140 <pre>
1141 struct {
1142         T     // conflicts with embedded field *T and *P.T
1143         *T    // conflicts with embedded field T and *P.T
1144         *P.T  // conflicts with embedded field T and *T
1145 }
1146 </pre>
1147
1148 <p>
1149 A field or <a href="#Method_declarations">method</a> <code>f</code> of an
1150 embedded field in a struct <code>x</code> is called <i>promoted</i> if
1151 <code>x.f</code> is a legal <a href="#Selectors">selector</a> that denotes
1152 that field or method <code>f</code>.
1153 </p>
1154
1155 <p>
1156 Promoted fields act like ordinary fields
1157 of a struct except that they cannot be used as field names in
1158 <a href="#Composite_literals">composite literals</a> of the struct.
1159 </p>
1160
1161 <p>
1162 Given a struct type <code>S</code> and a <a href="#Type_definitions">defined type</a>
1163 <code>T</code>, promoted methods are included in the method set of the struct as follows:
1164 </p>
1165 <ul>
1166         <li>
1167         If <code>S</code> contains an embedded field <code>T</code>,
1168         the <a href="#Method_sets">method sets</a> of <code>S</code>
1169         and <code>*S</code> both include promoted methods with receiver
1170         <code>T</code>. The method set of <code>*S</code> also
1171         includes promoted methods with receiver <code>*T</code>.
1172         </li>
1173
1174         <li>
1175         If <code>S</code> contains an embedded field <code>*T</code>,
1176         the method sets of <code>S</code> and <code>*S</code> both
1177         include promoted methods with receiver <code>T</code> or
1178         <code>*T</code>.
1179         </li>
1180 </ul>
1181
1182 <p>
1183 A field declaration may be followed by an optional string literal <i>tag</i>,
1184 which becomes an attribute for all the fields in the corresponding
1185 field declaration. An empty tag string is equivalent to an absent tag.
1186 The tags are made visible through a <a href="/pkg/reflect/#StructTag">reflection interface</a>
1187 and take part in <a href="#Type_identity">type identity</a> for structs
1188 but are otherwise ignored.
1189 </p>
1190
1191 <pre>
1192 struct {
1193         x, y float64 ""  // an empty tag string is like an absent tag
1194         name string  "any string is permitted as a tag"
1195         _    [4]byte "ceci n'est pas un champ de structure"
1196 }
1197
1198 // A struct corresponding to a TimeStamp protocol buffer.
1199 // The tag strings define the protocol buffer field numbers;
1200 // they follow the convention outlined by the reflect package.
1201 struct {
1202         microsec  uint64 `protobuf:"1"`
1203         serverIP6 uint64 `protobuf:"2"`
1204 }
1205 </pre>
1206
1207 <h3 id="Pointer_types">Pointer types</h3>
1208
1209 <p>
1210 A pointer type denotes the set of all pointers to <a href="#Variables">variables</a> of a given
1211 type, called the <i>base type</i> of the pointer.
1212 The value of an uninitialized pointer is <code>nil</code>.
1213 </p>
1214
1215 <pre class="ebnf">
1216 PointerType = "*" BaseType .
1217 BaseType    = Type .
1218 </pre>
1219
1220 <pre>
1221 *Point
1222 *[4]int
1223 </pre>
1224
1225 <h3 id="Function_types">Function types</h3>
1226
1227 <p>
1228 A function type denotes the set of all functions with the same parameter
1229 and result types. The value of an uninitialized variable of function type
1230 is <code>nil</code>.
1231 </p>
1232
1233 <pre class="ebnf">
1234 FunctionType   = "func" Signature .
1235 Signature      = Parameters [ Result ] .
1236 Result         = Parameters | Type .
1237 Parameters     = "(" [ ParameterList [ "," ] ] ")" .
1238 ParameterList  = ParameterDecl { "," ParameterDecl } .
1239 ParameterDecl  = [ IdentifierList ] [ "..." ] Type .
1240 </pre>
1241
1242 <p>
1243 Within a list of parameters or results, the names (IdentifierList)
1244 must either all be present or all be absent. If present, each name
1245 stands for one item (parameter or result) of the specified type and
1246 all non-<a href="#Blank_identifier">blank</a> names in the signature
1247 must be <a href="#Uniqueness_of_identifiers">unique</a>.
1248 If absent, each type stands for one item of that type.
1249 Parameter and result
1250 lists are always parenthesized except that if there is exactly
1251 one unnamed result it may be written as an unparenthesized type.
1252 </p>
1253
1254 <p>
1255 The final incoming parameter in a function signature may have
1256 a type prefixed with <code>...</code>.
1257 A function with such a parameter is called <i>variadic</i> and
1258 may be invoked with zero or more arguments for that parameter.
1259 </p>
1260
1261 <pre>
1262 func()
1263 func(x int) int
1264 func(a, _ int, z float32) bool
1265 func(a, b int, z float32) (bool)
1266 func(prefix string, values ...int)
1267 func(a, b int, z float64, opt ...interface{}) (success bool)
1268 func(int, int, float64) (float64, *[]int)
1269 func(n int) func(p *T)
1270 </pre>
1271
1272 <h3 id="Interface_types">Interface types</h3>
1273
1274 <p>
1275 An interface type defines a <i>type set</i>.
1276 A variable of interface type can store a value of any type that is in the type
1277 set of the interface. Such a type is said to <i>implement the interface</i>.
1278 The value of an uninitialized variable of interface type is <code>nil</code>.
1279 </p>
1280
1281 <pre class="ebnf">
1282 InterfaceType  = "interface" "{" { InterfaceElem ";" } "}" .
1283 InterfaceElem  = MethodElem | TypeElem .
1284 MethodElem     = MethodName Signature .
1285 MethodName     = identifier .
1286 TypeElem       = TypeTerm { "|" TypeTerm } .
1287 TypeTerm       = Type | UnderlyingType .
1288 UnderlyingType = "~" Type .
1289 </pre>
1290
1291 <p>
1292 An interface type is specified by a list of <i>interface elements</i>.
1293 An interface element is either a <i>method</i> or a <i>type element</i>,
1294 where a type element is a union of one or more <i>type terms</i>.
1295 A type term is either a single type or a single underlying type.
1296 </p>
1297
1298 <p>
1299 In its most basic form an interface specifies a (possibly empty) list of methods.
1300 The type set defined by such an interface is the set of types which implement all of
1301 those methods, and the corresponding <a href="#Method_sets">method set</a> consists
1302 exactly of the methods specified by the interface.
1303 </p>
1304
1305 <pre>
1306 // A simple File interface.
1307 interface {
1308         Read([]byte) (int, error)
1309         Write([]byte) (int, error)
1310         Close() error
1311 }
1312 </pre>
1313
1314 <p>
1315 The name of each explicitly specified method must be <a href="#Uniqueness_of_identifiers">unique</a>
1316 and not <a href="#Blank_identifier">blank</a>.
1317 </p>
1318
1319 <pre>
1320 interface {
1321         String() string
1322         String() string  // illegal: String not unique
1323         _(x int)         // illegal: method must have non-blank name
1324 }
1325 </pre>
1326
1327 <p>
1328 More than one type may implement an interface.
1329 For instance, if two types <code>S1</code> and <code>S2</code>
1330 have the method set
1331 </p>
1332
1333 <pre>
1334 func (p T) Read(p []byte) (n int, err error)
1335 func (p T) Write(p []byte) (n int, err error)
1336 func (p T) Close() error
1337 </pre>
1338
1339 <p>
1340 (where <code>T</code> stands for either <code>S1</code> or <code>S2</code>)
1341 then the <code>File</code> interface is implemented by both <code>S1</code> and
1342 <code>S2</code>, regardless of what other methods
1343 <code>S1</code> and <code>S2</code> may have or share.
1344 </p>
1345
1346 <p>
1347 Every type that is a member of the type set of an interface implements that interface.
1348 Any given type may implement several distinct interfaces.
1349 For instance, all types implement the <i>empty interface</i> which stands for the set of all types:
1350 </p>
1351
1352 <pre>
1353 interface{}
1354 </pre>
1355
1356 <p>
1357 For convenience, the predeclared type <code>any</code> is an alias for the empty interface.
1358 </p>
1359
1360 <p>
1361 Similarly, consider this interface specification,
1362 which appears within a <a href="#Type_declarations">type declaration</a>
1363 to define an interface called <code>Locker</code>:
1364 </p>
1365
1366 <pre>
1367 type Locker interface {
1368         Lock()
1369         Unlock()
1370 }
1371 </pre>
1372
1373 <p>
1374 If <code>S1</code> and <code>S2</code> also implement
1375 </p>
1376
1377 <pre>
1378 func (p T) Lock() { … }
1379 func (p T) Unlock() { … }
1380 </pre>
1381
1382 <p>
1383 they implement the <code>Locker</code> interface as well
1384 as the <code>File</code> interface.
1385 </p>
1386
1387 <p>
1388 In a slightly more general form
1389 an interface <code>T</code> may use a (possibly qualified) interface type
1390 name <code>E</code> as an interface element. This is called
1391 <i>embedding</i> interface <code>E</code> in <code>T</code>.
1392 The type set of <code>T</code> is the <i>intersection</i> of the type sets
1393 defined by <code>T</code>'s explicitly declared methods and the type sets
1394 of <code>T</code>’s embedded interfaces.
1395 In other words, the type set of <code>T</code> is the set of all types that implement all the
1396 explicitly declared methods of <code>T</code> and also all the methods of
1397 <code>E</code>.
1398 </p>
1399
1400 <pre>
1401 type Reader interface {
1402         Read(p []byte) (n int, err error)
1403         Close() error
1404 }
1405
1406 type Writer interface {
1407         Write(p []byte) (n int, err error)
1408         Close() error
1409 }
1410
1411 // ReadWriter's methods are Read, Write, and Close.
1412 type ReadWriter interface {
1413         Reader  // includes methods of Reader in ReadWriter's method set
1414         Writer  // includes methods of Writer in ReadWriter's method set
1415 }
1416 </pre>
1417
1418 <p>
1419 When embedding interfaces, methods with the
1420 <a href="#Uniqueness_of_identifiers">same</a> names must
1421 have <a href="#Type_identity">identical</a> signatures.
1422 </p>
1423
1424 <pre>
1425 type ReadCloser interface {
1426         Reader   // includes methods of Reader in ReadCloser's method set
1427         Close()  // illegal: signatures of Reader.Close and Close are different
1428 }
1429 </pre>
1430
1431 <p>
1432 Finally, in their most general form, an interface element may also be an arbitrary type term
1433 <code>T</code>, or a term of the form <code>~T</code> specifying the underlying type <code>T</code>,
1434 or a union of terms <code>t<sub>1</sub>|t<sub>2</sub>|…|t<sub>n</sub></code>.
1435 Together with method specifications, these elements enable the precise
1436 definition of an interface's type set as follows:
1437 </p>
1438
1439 <ul>
1440         <li>The type set of the empty interface is the set of all types.
1441         </li>
1442
1443         <li>The type set of a non-empty interface is the intersection of the type sets
1444                 of its interface elements.
1445         </li>
1446
1447         <li>The type set of a method specification is the set of types
1448                 whose method sets include that method.
1449         </li>
1450
1451         <li>The type set of a non-interface type term is the set consisting
1452                 of just that type.
1453         </li>
1454
1455         <li>The type set of a term of the form <code>~T</code>
1456                 is the set of types whose underlying type is <code>T</code>.
1457         </li>
1458
1459         <li>The type set of a <i>union</i> of terms
1460                 <code>t<sub>1</sub>|t<sub>2</sub>|…|t<sub>n</sub></code>
1461                 is the union of the type sets of the terms.
1462         </li>
1463 </ul>
1464
1465 <pre>
1466 // An interface representing only the type int.
1467 interface {
1468         int
1469 }
1470
1471 // An interface representing all types with underlying type int.
1472 interface {
1473         ~int
1474 }
1475
1476 // An interface representing all types with underlying type int which implement the String method.
1477 interface {
1478         ~int
1479         String() string
1480 }
1481
1482 // An interface representing an empty type set: there is no type that is both an int and a string.
1483 interface {
1484         int
1485         string
1486 }
1487 </pre>
1488
1489 <p>
1490 In a term of the form <code>~T</code>, the underlying type of <code>T</code>
1491 must be itself, and <code>T</code> cannot be an interface.
1492 </p>
1493
1494 <pre>
1495 type MyInt int
1496
1497 interface {
1498         ~[]byte  // the underlying type of []byte is itself
1499         ~MyInt   // illegal: the underlying type of MyInt is not MyInt
1500         ~error   // illegal: error is an interface
1501 }
1502 </pre>
1503
1504 <p>
1505 Union elements denote unions of type sets:
1506 </p>
1507
1508 <pre>
1509 // The Floats interface represents all floating-point types
1510 // (including any named types whose underlying types are
1511 // either float32 or float64).
1512 type Floats interface {
1513         ~float32 | ~float64
1514 }
1515 </pre>
1516
1517 <p>
1518 In a union, a term cannot be a type parameter, and the type sets of all
1519 non-interface terms must be pairwise disjoint (the pairwise intersection of the type sets must be empty).
1520 Given a type parameter <code>P</code>:
1521 </p>
1522
1523 <pre>
1524 interface {
1525         P                 // illegal: the term P is a type parameter
1526         int | P           // illegal: the term P is a type parameter
1527         ~int | MyInt      // illegal: the type sets for ~int and MyInt are not disjoint (~int includes MyInt)
1528         float32 | Floats  // overlapping type sets but Floats is an interface
1529 }
1530 </pre>
1531
1532 <p>
1533 Implementation restriction:
1534 A union with more than one term cannot contain interface types
1535 with non-empty <a href="#Method_sets">method sets</a> or which
1536 are or embed the <a href="#Predeclared_identifiers">predeclared identifier</a>
1537 <code>comparable</code>.
1538 </p>
1539
1540 <p>
1541 Interfaces that contain non-interface types, terms of the form <code>~T</code>,
1542 or unions may only be used as type constraints, or as elements of other interfaces used
1543 as constraints. They cannot be the types of values or variables, or components of other,
1544 non-interface types.
1545 </p>
1546
1547 <pre>
1548 var x Floats                     // illegal: Floats is restricted by float32 and float64
1549
1550 var x interface{} = Floats(nil)  // illegal
1551
1552 type Floatish struct {
1553         f Floats                 // illegal
1554 }
1555 </pre>
1556
1557 <!-- TODO The rule below needs to be generalized to interface elements.
1558           It should be factored out and generalized to other types
1559           such as arrays and structs which are currently missing such a
1560           rule. See also #5069.
1561 -->
1562
1563 <p>
1564 An interface type <code>T</code> may not embed itself
1565 or any interface type that embeds <code>T</code>, recursively.
1566 </p>
1567
1568 <pre>
1569 // illegal: Bad cannot embed itself
1570 type Bad interface {
1571         Bad
1572 }
1573
1574 // illegal: Bad1 cannot embed itself using Bad2
1575 type Bad1 interface {
1576         Bad2
1577 }
1578 type Bad2 interface {
1579         Bad1
1580 }
1581 </pre>
1582
1583 <h3 id="Map_types">Map types</h3>
1584
1585 <p>
1586 A map is an unordered group of elements of one type, called the
1587 element type, indexed by a set of unique <i>keys</i> of another type,
1588 called the key type.
1589 The value of an uninitialized map is <code>nil</code>.
1590 </p>
1591
1592 <pre class="ebnf">
1593 MapType     = "map" "[" KeyType "]" ElementType .
1594 KeyType     = Type .
1595 </pre>
1596
1597 <p>
1598 The <a href="#Comparison_operators">comparison operators</a>
1599 <code>==</code> and <code>!=</code> must be fully defined
1600 for operands of the key type; thus the key type must not be a function, map, or
1601 slice.
1602 If the key type is an interface type, these
1603 comparison operators must be defined for the dynamic key values;
1604 failure will cause a <a href="#Run_time_panics">run-time panic</a>.
1605 </p>
1606
1607 <pre>
1608 map[string]int
1609 map[*T]struct{ x, y float64 }
1610 map[string]interface{}
1611 </pre>
1612
1613 <p>
1614 The number of map elements is called its length.
1615 For a map <code>m</code>, it can be discovered using the
1616 built-in function <a href="#Length_and_capacity"><code>len</code></a>
1617 and may change during execution. Elements may be added during execution
1618 using <a href="#Assignments">assignments</a> and retrieved with
1619 <a href="#Index_expressions">index expressions</a>; they may be removed with the
1620 <a href="#Deletion_of_map_elements"><code>delete</code></a> built-in function.
1621 </p>
1622 <p>
1623 A new, empty map value is made using the built-in
1624 function <a href="#Making_slices_maps_and_channels"><code>make</code></a>,
1625 which takes the map type and an optional capacity hint as arguments:
1626 </p>
1627
1628 <pre>
1629 make(map[string]int)
1630 make(map[string]int, 100)
1631 </pre>
1632
1633 <p>
1634 The initial capacity does not bound its size:
1635 maps grow to accommodate the number of items
1636 stored in them, with the exception of <code>nil</code> maps.
1637 A <code>nil</code> map is equivalent to an empty map except that no elements
1638 may be added.
1639
1640 <h3 id="Channel_types">Channel types</h3>
1641
1642 <p>
1643 A channel provides a mechanism for
1644 <a href="#Go_statements">concurrently executing functions</a>
1645 to communicate by
1646 <a href="#Send_statements">sending</a> and
1647 <a href="#Receive_operator">receiving</a>
1648 values of a specified element type.
1649 The value of an uninitialized channel is <code>nil</code>.
1650 </p>
1651
1652 <pre class="ebnf">
1653 ChannelType = ( "chan" | "chan" "&lt;-" | "&lt;-" "chan" ) ElementType .
1654 </pre>
1655
1656 <p>
1657 The optional <code>&lt;-</code> operator specifies the channel <i>direction</i>,
1658 <i>send</i> or <i>receive</i>. If a direction is given, the channel is <i>directional</i>,
1659 otherwise it is <i>bidirectional</i>.
1660 A channel may be constrained only to send or only to receive by
1661 <a href="#Assignments">assignment</a> or
1662 explicit <a href="#Conversions">conversion</a>.
1663 </p>
1664
1665 <pre>
1666 chan T          // can be used to send and receive values of type T
1667 chan&lt;- float64  // can only be used to send float64s
1668 &lt;-chan int      // can only be used to receive ints
1669 </pre>
1670
1671 <p>
1672 The <code>&lt;-</code> operator associates with the leftmost <code>chan</code>
1673 possible:
1674 </p>
1675
1676 <pre>
1677 chan&lt;- chan int    // same as chan&lt;- (chan int)
1678 chan&lt;- &lt;-chan int  // same as chan&lt;- (&lt;-chan int)
1679 &lt;-chan &lt;-chan int  // same as &lt;-chan (&lt;-chan int)
1680 chan (&lt;-chan int)
1681 </pre>
1682
1683 <p>
1684 A new, initialized channel
1685 value can be made using the built-in function
1686 <a href="#Making_slices_maps_and_channels"><code>make</code></a>,
1687 which takes the channel type and an optional <i>capacity</i> as arguments:
1688 </p>
1689
1690 <pre>
1691 make(chan int, 100)
1692 </pre>
1693
1694 <p>
1695 The capacity, in number of elements, sets the size of the buffer in the channel.
1696 If the capacity is zero or absent, the channel is unbuffered and communication
1697 succeeds only when both a sender and receiver are ready. Otherwise, the channel
1698 is buffered and communication succeeds without blocking if the buffer
1699 is not full (sends) or not empty (receives).
1700 A <code>nil</code> channel is never ready for communication.
1701 </p>
1702
1703 <p>
1704 A channel may be closed with the built-in function
1705 <a href="#Close"><code>close</code></a>.
1706 The multi-valued assignment form of the
1707 <a href="#Receive_operator">receive operator</a>
1708 reports whether a received value was sent before
1709 the channel was closed.
1710 </p>
1711
1712 <p>
1713 A single channel may be used in
1714 <a href="#Send_statements">send statements</a>,
1715 <a href="#Receive_operator">receive operations</a>,
1716 and calls to the built-in functions
1717 <a href="#Length_and_capacity"><code>cap</code></a> and
1718 <a href="#Length_and_capacity"><code>len</code></a>
1719 by any number of goroutines without further synchronization.
1720 Channels act as first-in-first-out queues.
1721 For example, if one goroutine sends values on a channel
1722 and a second goroutine receives them, the values are
1723 received in the order sent.
1724 </p>
1725
1726 <h3 id="Type_parameters">Type parameters</h3>
1727
1728 <p>
1729 A <i>type parameter</i> is an (unqualified) type name declared in the
1730 <a href="#Type_parameter_lists">type parameter list</a> of a
1731 <a href="#Function_declarations">function declaration</a> or
1732 <a href="#Type_definitions">type definition</a>; or in the receiver specification
1733 of a <a href="#Method_declarations">method declaration</a> that is associated
1734 with a parameterized type.
1735 A type parameter acts as a place holder for an (as of yet) unknown type in the declaration;
1736 the type parameter is replaced with a <i>type argument</i> upon
1737 <a href="#Instantiations">instantiation</a> of the parameterized function or type.
1738 </p>
1739
1740 <p>
1741 The properties of a type parameter are determined by its
1742 <a href="#Type_constraints">type constraint</a>.
1743 </p>
1744
1745 <h2 id="Properties_of_types_and_values">Properties of types and values</h2>
1746
1747 <h3 id="Type_identity">Type identity</h3>
1748
1749 <p>
1750 Two types are either <i>identical</i> or <i>different</i>.
1751 </p>
1752
1753 <p>
1754 A <a href="#Types">named type</a> is always different from any other type.
1755 Otherwise, two types are identical if their <a href="#Types">underlying</a> type literals are
1756 structurally equivalent; that is, they have the same literal structure and corresponding
1757 components have identical types. In detail:
1758 </p>
1759
1760 <ul>
1761         <li>Two array types are identical if they have identical element types and
1762             the same array length.</li>
1763
1764         <li>Two slice types are identical if they have identical element types.</li>
1765
1766         <li>Two struct types are identical if they have the same sequence of fields,
1767             and if corresponding fields have the same names, and identical types,
1768             and identical tags.
1769             <a href="#Exported_identifiers">Non-exported</a> field names from different
1770             packages are always different.</li>
1771
1772         <li>Two pointer types are identical if they have identical base types.</li>
1773
1774         <li>Two function types are identical if they have the same number of parameters
1775             and result values, corresponding parameter and result types are
1776             identical, and either both functions are variadic or neither is.
1777             Parameter and result names are not required to match.</li>
1778
1779         <li>Two interface types are identical if they define the same type set.
1780         </li>
1781
1782         <li>Two map types are identical if they have identical key and element types.</li>
1783
1784         <li>Two channel types are identical if they have identical element types and
1785             the same direction.</li>
1786
1787         <li>Two <a href="#Instantiations">instantiated</a> types are identical if
1788             their defined types and all type arguments are identical.
1789         </li>
1790 </ul>
1791
1792 <p>
1793 Given the declarations
1794 </p>
1795
1796 <pre>
1797 type (
1798         A0 = []string
1799         A1 = A0
1800         A2 = struct{ a, b int }
1801         A3 = int
1802         A4 = func(A3, float64) *A0
1803         A5 = func(x int, _ float64) *[]string
1804
1805         B0 A0
1806         B1 []string
1807         B2 struct{ a, b int }
1808         B3 struct{ a, c int }
1809         B4 func(int, float64) *B0
1810         B5 func(x int, y float64) *A1
1811
1812         C0 = B0
1813         D0[P1, P2 any] struct{ x P1; y P2 }
1814         E0 = D0[int, string]
1815 )
1816 </pre>
1817
1818 <p>
1819 these types are identical:
1820 </p>
1821
1822 <pre>
1823 A0, A1, and []string
1824 A2 and struct{ a, b int }
1825 A3 and int
1826 A4, func(int, float64) *[]string, and A5
1827
1828 B0 and C0
1829 D0[int, string] and E0
1830 []int and []int
1831 struct{ a, b *T5 } and struct{ a, b *T5 }
1832 func(x int, y float64) *[]string, func(int, float64) (result *[]string), and A5
1833 </pre>
1834
1835 <p>
1836 <code>B0</code> and <code>B1</code> are different because they are new types
1837 created by distinct <a href="#Type_definitions">type definitions</a>;
1838 <code>func(int, float64) *B0</code> and <code>func(x int, y float64) *[]string</code>
1839 are different because <code>B0</code> is different from <code>[]string</code>;
1840 and <code>P1</code> and <code>P2</code> are different because they are different
1841 type parameters.
1842 <code>D0[int, string]</code> and <code>struct{ x int; y string }</code> are
1843 different because the former is an <a href="#Instantiations">instantiated</a>
1844 defined type while the latter is a type literal
1845 (but they are still <a href="#Assignability">assignable</a>).
1846 </p>
1847
1848 <h3 id="Assignability">Assignability</h3>
1849
1850 <p>
1851 A value <code>x</code> is <i>assignable</i> to a <a href="#Variables">variable</a> of type <code>T</code>
1852 ("<code>x</code> is assignable to <code>T</code>") if one of the following conditions applies:
1853 </p>
1854
1855 <ul>
1856 <li>
1857 <code>x</code>'s type is identical to <code>T</code>.
1858 </li>
1859 <li>
1860 <code>x</code>'s type <code>V</code> and <code>T</code> have identical
1861 <a href="#Underlying_types">underlying types</a> and at least one of <code>V</code>
1862 or <code>T</code> is not a <a href="#Types">named type</a>.
1863 </li>
1864 <li>
1865 <code>x</code>'s type <code>V</code> and <code>T</code> are channel types with
1866 identical element types, <code>V</code> is a bidirectional channel,
1867 and at least one of <code>V</code> or <code>T</code> is not a <a href="#Types">named type</a>.
1868 </li>
1869 <li>
1870 <code>T</code> is an interface type, but not a type parameter, and
1871 <code>x</code> <a href="#Interface_types">implements</a> <code>T</code>.
1872 </li>
1873 <li>
1874 <code>x</code> is the predeclared identifier <code>nil</code> and <code>T</code>
1875 is a pointer, function, slice, map, channel, or interface type,
1876 but not a type parameter.
1877 </li>
1878 <li>
1879 <code>x</code> is an untyped <a href="#Constants">constant</a>
1880 <a href="#Representability">representable</a>
1881 by a value of type <code>T</code>.
1882 </li>
1883 </ul>
1884
1885 <p>
1886 Additionally, if <code>x's</code> type <code>V</code> or <code>T</code> are type parameters
1887 with <a href="#Structure_of_interfaces">specific types</a>, <code>x</code>
1888 is assignable to a variable of type <code>T</code> if one of the following conditions applies:
1889 </p>
1890
1891 <ul>
1892 <li>
1893 <code>x</code> is the predeclared identifier <code>nil</code>, <code>T</code> is
1894 a type parameter, and <code>x</code> is assignable to each specific type of
1895 <code>T</code>.
1896 </li>
1897 <li>
1898 <code>V</code> is not a <a href="#Types">named type</a>, <code>T</code> is
1899 a type parameter, and <code>x</code> is assignable to each specific type of
1900 <code>T</code>.
1901 </li>
1902 <li>
1903 <code>V</code> is a type parameter and <code>T</code> is not a named type,
1904 and values of each specific type of <code>V</code> are assignable
1905 to <code>T</code>.
1906 </li>
1907 </ul>
1908
1909 <h3 id="Representability">Representability</h3>
1910
1911 <p>
1912 A <a href="#Constants">constant</a> <code>x</code> is <i>representable</i>
1913 by a value of type <code>T</code>,
1914 where <code>T</code> is not a <a href="#Type_parameters">type parameter</a>,
1915 if one of the following conditions applies:
1916 </p>
1917
1918 <ul>
1919 <li>
1920 <code>x</code> is in the set of values <a href="#Types">determined</a> by <code>T</code>.
1921 </li>
1922
1923 <li>
1924 <code>T</code> is a floating-point type and <code>x</code> can be rounded to <code>T</code>'s
1925 precision without overflow. Rounding uses IEEE 754 round-to-even rules but with an IEEE
1926 negative zero further simplified to an unsigned zero. Note that constant values never result
1927 in an IEEE negative zero, NaN, or infinity.
1928 </li>
1929
1930 <li>
1931 <code>T</code> is a complex type, and <code>x</code>'s
1932 <a href="#Complex_numbers">components</a> <code>real(x)</code> and <code>imag(x)</code>
1933 are representable by values of <code>T</code>'s component type (<code>float32</code> or
1934 <code>float64</code>).
1935 </li>
1936 </ul>
1937
1938 <p>
1939 If <code>T</code> is a type parameter with <a href="#Structure_of_interfaces">specific types</a>,
1940 <code>x</code> is representable by a value of type <code>T</code> if <code>x</code> is representable
1941 by a value of each specific type of <code>T</code>.
1942 </p>
1943
1944 <pre>
1945 x                   T           x is representable by a value of T because
1946
1947 'a'                 byte        97 is in the set of byte values
1948 97                  rune        rune is an alias for int32, and 97 is in the set of 32-bit integers
1949 "foo"               string      "foo" is in the set of string values
1950 1024                int16       1024 is in the set of 16-bit integers
1951 42.0                byte        42 is in the set of unsigned 8-bit integers
1952 1e10                uint64      10000000000 is in the set of unsigned 64-bit integers
1953 2.718281828459045   float32     2.718281828459045 rounds to 2.7182817 which is in the set of float32 values
1954 -1e-1000            float64     -1e-1000 rounds to IEEE -0.0 which is further simplified to 0.0
1955 0i                  int         0 is an integer value
1956 (42 + 0i)           float32     42.0 (with zero imaginary part) is in the set of float32 values
1957 </pre>
1958
1959 <pre>
1960 x                   T           x is not representable by a value of T because
1961
1962 0                   bool        0 is not in the set of boolean values
1963 'a'                 string      'a' is a rune, it is not in the set of string values
1964 1024                byte        1024 is not in the set of unsigned 8-bit integers
1965 -1                  uint16      -1 is not in the set of unsigned 16-bit integers
1966 1.1                 int         1.1 is not an integer value
1967 42i                 float32     (0 + 42i) is not in the set of float32 values
1968 1e1000              float64     1e1000 overflows to IEEE +Inf after rounding
1969 </pre>
1970
1971 <h3 id="Structure_of_interfaces">Structure of interfaces</h3>
1972
1973 <p>
1974 An interface specification which contains <a href="#Interface_types">type elements</a>
1975 defines a (possibly empty) set of <i>specific types</i>.
1976 Loosely speaking, these are the types <code>T</code> that appear in the
1977 interface definition in terms of the form <code>T</code>, <code>~T</code>,
1978 or in unions of such terms.
1979 </p>
1980
1981 <p>
1982 More precisely, for a given interface, the set of specific types corresponds to
1983 the set 𝑅 of representative types of the interface, if 𝑅 is non-empty and finite.
1984 Otherwise, if 𝑅 is empty or infinite, the interface has <i>no specific types</i>.
1985 </p>
1986
1987 <p>
1988 For a given interface, type element or type term, the set 𝑅 of representative types is defined as follows:
1989 </p>
1990
1991 <ul>
1992         <li>For an interface with no type elements, 𝑅 is the (infinite) set of all types.
1993         </li>
1994
1995         <li>For an interface with type elements,
1996                 𝑅 is the intersection of the representative types of its type elements.
1997         </li>
1998
1999         <li>For a non-interface type term <code>T</code> or a term of the form <code>~T</code>,
2000                 𝑅 is the set consisting of the type <code>T</code>.
2001         </li>
2002
2003         <li>For a <i>union</i> of terms
2004                 <code>t<sub>1</sub>|t<sub>2</sub>|…|t<sub>n</sub></code>,
2005                 𝑅 is the union of the representative types of the terms.
2006         </li>
2007 </ul>
2008
2009 <p>
2010 An interface may have specific types even if its <a href="#Interface_types">type set</a>
2011 is empty.
2012 </p>
2013
2014 <p>
2015 Examples of interfaces with their specific types:
2016 </p>
2017
2018 <pre>
2019 type Celsius float32
2020 type Kelvin  float32
2021
2022 interface{}                    // no specific types
2023 interface{ int }               // int
2024 interface{ ~string }           // string
2025 interface{ int|~string }       // int, string
2026 interface{ Celsius|Kelvin }    // Celsius, Kelvin
2027 interface{ float64|any }       // no specific types (union is all types)
2028 interface{ int; m() }          // int (but type set is empty because int has no method m)
2029 interface{ ~int; m() }         // int (but type set is infinite because many integer types have a method m)
2030 interface{ int; any }          // int
2031 interface{ int; string }       // no specific types (intersection is empty)
2032 </pre>
2033
2034 <p>
2035 An interface <code>T</code> is called <i>structural</i> if one of the following
2036 conditions is satisfied:
2037 </p>
2038
2039 <ol>
2040 <li>
2041 There is a single type <code>U</code> which is the <a href="#Underlying_types">underlying type</a>
2042 of all types in the <a href="#Interface_types">type set</a> of <code>T</code>; or
2043 </li>
2044 <li>
2045 the type set of <code>T</code> contains only <a href="#Channel_types">channel types</a>
2046 with identical element type <code>E</code>, and all directional channels have the same
2047 direction.
2048 </li>
2049 </ol>
2050
2051 <p>
2052 A structural interface has a <i>structural type</i> which is, depending on the
2053 condition that is satisfied, either:
2054 </p>
2055
2056 <ol>
2057 <li>
2058 the type <code>U</code>; or
2059 </li>
2060 <li>
2061 the type <code>chan E</code> if <code>T</code> contains only bidirectional
2062 channels, or the type <code>chan&lt;- E</code> or <code>&lt;-chan E</code>
2063 depending on the direction of the directional channels present.
2064 </li>
2065 </ol>
2066
2067 <p>
2068 Examples of structural interfaces with their structural types:
2069 </p>
2070
2071 <pre>
2072 interface{ int }                          // int
2073 interface{ Celsius|Kelvin }               // float32
2074 interface{ ~chan int }                    // chan int
2075 interface{ ~chan int|~chan&lt;- int }        // chan&lt;- int
2076 interface{ ~[]*data; String() string }    // []*data
2077 </pre>
2078
2079 <p>
2080 Examples of non-structural interfaces:
2081 </p>
2082
2083 <pre>
2084 interface{}                               // no single underlying type
2085 interface{ Celsius|float64 }              // no single underlying type
2086 interface{ chan int | chan&lt;- string }     // channels have different element types
2087 interface{ &lt;-chan int | chan&lt;- int }      // directional channels have different directions
2088 </pre>
2089
2090 <h2 id="Blocks">Blocks</h2>
2091
2092 <p>
2093 A <i>block</i> is a possibly empty sequence of declarations and statements
2094 within matching brace brackets.
2095 </p>
2096
2097 <pre class="ebnf">
2098 Block = "{" StatementList "}" .
2099 StatementList = { Statement ";" } .
2100 </pre>
2101
2102 <p>
2103 In addition to explicit blocks in the source code, there are implicit blocks:
2104 </p>
2105
2106 <ol>
2107         <li>The <i>universe block</i> encompasses all Go source text.</li>
2108
2109         <li>Each <a href="#Packages">package</a> has a <i>package block</i> containing all
2110             Go source text for that package.</li>
2111
2112         <li>Each file has a <i>file block</i> containing all Go source text
2113             in that file.</li>
2114
2115         <li>Each <a href="#If_statements">"if"</a>,
2116             <a href="#For_statements">"for"</a>, and
2117             <a href="#Switch_statements">"switch"</a>
2118             statement is considered to be in its own implicit block.</li>
2119
2120         <li>Each clause in a <a href="#Switch_statements">"switch"</a>
2121             or <a href="#Select_statements">"select"</a> statement
2122             acts as an implicit block.</li>
2123 </ol>
2124
2125 <p>
2126 Blocks nest and influence <a href="#Declarations_and_scope">scoping</a>.
2127 </p>
2128
2129
2130 <h2 id="Declarations_and_scope">Declarations and scope</h2>
2131
2132 <p>
2133 A <i>declaration</i> binds a non-<a href="#Blank_identifier">blank</a> identifier to a
2134 <a href="#Constant_declarations">constant</a>,
2135 <a href="#Type_declarations">type</a>,
2136 <a href="#Variable_declarations">variable</a>,
2137 <a href="#Function_declarations">function</a>,
2138 <a href="#Labeled_statements">label</a>, or
2139 <a href="#Import_declarations">package</a>.
2140 Every identifier in a program must be declared.
2141 No identifier may be declared twice in the same block, and
2142 no identifier may be declared in both the file and package block.
2143 </p>
2144
2145 <p>
2146 The <a href="#Blank_identifier">blank identifier</a> may be used like any other identifier
2147 in a declaration, but it does not introduce a binding and thus is not declared.
2148 In the package block, the identifier <code>init</code> may only be used for
2149 <a href="#Package_initialization"><code>init</code> function</a> declarations,
2150 and like the blank identifier it does not introduce a new binding.
2151 </p>
2152
2153 <pre class="ebnf">
2154 Declaration   = ConstDecl | TypeDecl | VarDecl .
2155 TopLevelDecl  = Declaration | FunctionDecl | MethodDecl .
2156 </pre>
2157
2158 <p>
2159 The <i>scope</i> of a declared identifier is the extent of source text in which
2160 the identifier denotes the specified constant, type, variable, function, label, or package.
2161 </p>
2162
2163 <p>
2164 Go is lexically scoped using <a href="#Blocks">blocks</a>:
2165 </p>
2166
2167 <ol>
2168         <li>The scope of a <a href="#Predeclared_identifiers">predeclared identifier</a> is the universe block.</li>
2169
2170         <li>The scope of an identifier denoting a constant, type, variable,
2171             or function (but not method) declared at top level (outside any
2172             function) is the package block.</li>
2173
2174         <li>The scope of the package name of an imported package is the file block
2175             of the file containing the import declaration.</li>
2176
2177         <li>The scope of an identifier denoting a method receiver, function parameter,
2178             or result variable is the function body.</li>
2179
2180         <li>The scope of an identifier denoting a type parameter of a type-parameterized function
2181             or declared by a method receiver is the function body and all parameter lists of the
2182             function.
2183         </li>
2184
2185         <li>The scope of an identifier denoting a type parameter of a parameterized type
2186             begins after the name of the parameterized type and ends at the end
2187             of the TypeSpec.</li>
2188
2189         <li>The scope of a constant or variable identifier declared
2190             inside a function begins at the end of the ConstSpec or VarSpec
2191             (ShortVarDecl for short variable declarations)
2192             and ends at the end of the innermost containing block.</li>
2193
2194         <li>The scope of a type identifier declared inside a function
2195             begins at the identifier in the TypeSpec
2196             and ends at the end of the innermost containing block.</li>
2197 </ol>
2198
2199 <p>
2200 An identifier declared in a block may be redeclared in an inner block.
2201 While the identifier of the inner declaration is in scope, it denotes
2202 the entity declared by the inner declaration.
2203 </p>
2204
2205 <p>
2206 The <a href="#Package_clause">package clause</a> is not a declaration; the package name
2207 does not appear in any scope. Its purpose is to identify the files belonging
2208 to the same <a href="#Packages">package</a> and to specify the default package name for import
2209 declarations.
2210 </p>
2211
2212
2213 <h3 id="Label_scopes">Label scopes</h3>
2214
2215 <p>
2216 Labels are declared by <a href="#Labeled_statements">labeled statements</a> and are
2217 used in the <a href="#Break_statements">"break"</a>,
2218 <a href="#Continue_statements">"continue"</a>, and
2219 <a href="#Goto_statements">"goto"</a> statements.
2220 It is illegal to define a label that is never used.
2221 In contrast to other identifiers, labels are not block scoped and do
2222 not conflict with identifiers that are not labels. The scope of a label
2223 is the body of the function in which it is declared and excludes
2224 the body of any nested function.
2225 </p>
2226
2227
2228 <h3 id="Blank_identifier">Blank identifier</h3>
2229
2230 <p>
2231 The <i>blank identifier</i> is represented by the underscore character <code>_</code>.
2232 It serves as an anonymous placeholder instead of a regular (non-blank)
2233 identifier and has special meaning in <a href="#Declarations_and_scope">declarations</a>,
2234 as an <a href="#Operands">operand</a>, and in <a href="#Assignments">assignments</a>.
2235 </p>
2236
2237
2238 <h3 id="Predeclared_identifiers">Predeclared identifiers</h3>
2239
2240 <p>
2241 The following identifiers are implicitly declared in the
2242 <a href="#Blocks">universe block</a>:
2243 </p>
2244 <pre class="grammar">
2245 Types:
2246         any bool byte comparable
2247         complex64 complex128 error float32 float64
2248         int int8 int16 int32 int64 rune string
2249         uint uint8 uint16 uint32 uint64 uintptr
2250
2251 Constants:
2252         true false iota
2253
2254 Zero value:
2255         nil
2256
2257 Functions:
2258         append cap close complex copy delete imag len
2259         make new panic print println real recover
2260 </pre>
2261
2262 <h3 id="Exported_identifiers">Exported identifiers</h3>
2263
2264 <p>
2265 An identifier may be <i>exported</i> to permit access to it from another package.
2266 An identifier is exported if both:
2267 </p>
2268 <ol>
2269         <li>the first character of the identifier's name is a Unicode upper case
2270         letter (Unicode class "Lu"); and</li>
2271         <li>the identifier is declared in the <a href="#Blocks">package block</a>
2272         or it is a <a href="#Struct_types">field name</a> or
2273         <a href="#MethodName">method name</a>.</li>
2274 </ol>
2275 <p>
2276 All other identifiers are not exported.
2277 </p>
2278
2279 <h3 id="Uniqueness_of_identifiers">Uniqueness of identifiers</h3>
2280
2281 <p>
2282 Given a set of identifiers, an identifier is called <i>unique</i> if it is
2283 <i>different</i> from every other in the set.
2284 Two identifiers are different if they are spelled differently, or if they
2285 appear in different <a href="#Packages">packages</a> and are not
2286 <a href="#Exported_identifiers">exported</a>. Otherwise, they are the same.
2287 </p>
2288
2289 <h3 id="Constant_declarations">Constant declarations</h3>
2290
2291 <p>
2292 A constant declaration binds a list of identifiers (the names of
2293 the constants) to the values of a list of <a href="#Constant_expressions">constant expressions</a>.
2294 The number of identifiers must be equal
2295 to the number of expressions, and the <i>n</i>th identifier on
2296 the left is bound to the value of the <i>n</i>th expression on the
2297 right.
2298 </p>
2299
2300 <pre class="ebnf">
2301 ConstDecl      = "const" ( ConstSpec | "(" { ConstSpec ";" } ")" ) .
2302 ConstSpec      = IdentifierList [ [ Type ] "=" ExpressionList ] .
2303
2304 IdentifierList = identifier { "," identifier } .
2305 ExpressionList = Expression { "," Expression } .
2306 </pre>
2307
2308 <p>
2309 If the type is present, all constants take the type specified, and
2310 the expressions must be <a href="#Assignability">assignable</a> to that type.
2311 If the type is omitted, the constants take the
2312 individual types of the corresponding expressions.
2313 If the expression values are untyped <a href="#Constants">constants</a>,
2314 the declared constants remain untyped and the constant identifiers
2315 denote the constant values. For instance, if the expression is a
2316 floating-point literal, the constant identifier denotes a floating-point
2317 constant, even if the literal's fractional part is zero.
2318 </p>
2319
2320 <pre>
2321 const Pi float64 = 3.14159265358979323846
2322 const zero = 0.0         // untyped floating-point constant
2323 const (
2324         size int64 = 1024
2325         eof        = -1  // untyped integer constant
2326 )
2327 const a, b, c = 3, 4, "foo"  // a = 3, b = 4, c = "foo", untyped integer and string constants
2328 const u, v float32 = 0, 3    // u = 0.0, v = 3.0
2329 </pre>
2330
2331 <p>
2332 Within a parenthesized <code>const</code> declaration list the
2333 expression list may be omitted from any but the first ConstSpec.
2334 Such an empty list is equivalent to the textual substitution of the
2335 first preceding non-empty expression list and its type if any.
2336 Omitting the list of expressions is therefore equivalent to
2337 repeating the previous list.  The number of identifiers must be equal
2338 to the number of expressions in the previous list.
2339 Together with the <a href="#Iota"><code>iota</code> constant generator</a>
2340 this mechanism permits light-weight declaration of sequential values:
2341 </p>
2342
2343 <pre>
2344 const (
2345         Sunday = iota
2346         Monday
2347         Tuesday
2348         Wednesday
2349         Thursday
2350         Friday
2351         Partyday
2352         numberOfDays  // this constant is not exported
2353 )
2354 </pre>
2355
2356
2357 <h3 id="Iota">Iota</h3>
2358
2359 <p>
2360 Within a <a href="#Constant_declarations">constant declaration</a>, the predeclared identifier
2361 <code>iota</code> represents successive untyped integer <a href="#Constants">
2362 constants</a>. Its value is the index of the respective <a href="#ConstSpec">ConstSpec</a>
2363 in that constant declaration, starting at zero.
2364 It can be used to construct a set of related constants:
2365 </p>
2366
2367 <pre>
2368 const (
2369         c0 = iota  // c0 == 0
2370         c1 = iota  // c1 == 1
2371         c2 = iota  // c2 == 2
2372 )
2373
2374 const (
2375         a = 1 &lt;&lt; iota  // a == 1  (iota == 0)
2376         b = 1 &lt;&lt; iota  // b == 2  (iota == 1)
2377         c = 3          // c == 3  (iota == 2, unused)
2378         d = 1 &lt;&lt; iota  // d == 8  (iota == 3)
2379 )
2380
2381 const (
2382         u         = iota * 42  // u == 0     (untyped integer constant)
2383         v float64 = iota * 42  // v == 42.0  (float64 constant)
2384         w         = iota * 42  // w == 84    (untyped integer constant)
2385 )
2386
2387 const x = iota  // x == 0
2388 const y = iota  // y == 0
2389 </pre>
2390
2391 <p>
2392 By definition, multiple uses of <code>iota</code> in the same ConstSpec all have the same value:
2393 </p>
2394
2395 <pre>
2396 const (
2397         bit0, mask0 = 1 &lt;&lt; iota, 1&lt;&lt;iota - 1  // bit0 == 1, mask0 == 0  (iota == 0)
2398         bit1, mask1                           // bit1 == 2, mask1 == 1  (iota == 1)
2399         _, _                                  //                        (iota == 2, unused)
2400         bit3, mask3                           // bit3 == 8, mask3 == 7  (iota == 3)
2401 )
2402 </pre>
2403
2404 <p>
2405 This last example exploits the <a href="#Constant_declarations">implicit repetition</a>
2406 of the last non-empty expression list.
2407 </p>
2408
2409
2410 <h3 id="Type_declarations">Type declarations</h3>
2411
2412 <p>
2413 A type declaration binds an identifier, the <i>type name</i>, to a <a href="#Types">type</a>.
2414 Type declarations come in two forms: alias declarations and type definitions.
2415 </p>
2416
2417 <pre class="ebnf">
2418 TypeDecl = "type" ( TypeSpec | "(" { TypeSpec ";" } ")" ) .
2419 TypeSpec = AliasDecl | TypeDef .
2420 </pre>
2421
2422 <h4 id="Alias_declarations">Alias declarations</h4>
2423
2424 <p>
2425 An alias declaration binds an identifier to the given type.
2426 </p>
2427
2428 <pre class="ebnf">
2429 AliasDecl = identifier "=" Type .
2430 </pre>
2431
2432 <p>
2433 Within the <a href="#Declarations_and_scope">scope</a> of
2434 the identifier, it serves as an <i>alias</i> for the type.
2435 </p>
2436
2437 <pre>
2438 type (
2439         nodeList = []*Node  // nodeList and []*Node are identical types
2440         Polar    = polar    // Polar and polar denote identical types
2441 )
2442 </pre>
2443
2444
2445 <h4 id="Type_definitions">Type definitions</h4>
2446
2447 <p>
2448 A type definition creates a new, distinct type with the same
2449 <a href="#Types">underlying type</a> and operations as the given type
2450 and binds an identifier, the <i>type name</i>, to it.
2451 </p>
2452
2453 <pre class="ebnf">
2454 TypeDef = identifier [ TypeParameters ] Type .
2455 </pre>
2456
2457 <p>
2458 The new type is called a <i>defined type</i>.
2459 It is <a href="#Type_identity">different</a> from any other type,
2460 including the type it is created from.
2461 </p>
2462
2463 <pre>
2464 type (
2465         Point struct{ x, y float64 }  // Point and struct{ x, y float64 } are different types
2466         polar Point                   // polar and Point denote different types
2467 )
2468
2469 type TreeNode struct {
2470         left, right *TreeNode
2471         value *Comparable
2472 }
2473
2474 type Block interface {
2475         BlockSize() int
2476         Encrypt(src, dst []byte)
2477         Decrypt(src, dst []byte)
2478 }
2479 </pre>
2480
2481 <p>
2482 A defined type may have <a href="#Method_declarations">methods</a> associated with it.
2483 It does not inherit any methods bound to the given type,
2484 but the <a href="#Method_sets">method set</a>
2485 of an interface type or of elements of a composite type remains unchanged:
2486 </p>
2487
2488 <pre>
2489 // A Mutex is a data type with two methods, Lock and Unlock.
2490 type Mutex struct         { /* Mutex fields */ }
2491 func (m *Mutex) Lock()    { /* Lock implementation */ }
2492 func (m *Mutex) Unlock()  { /* Unlock implementation */ }
2493
2494 // NewMutex has the same composition as Mutex but its method set is empty.
2495 type NewMutex Mutex
2496
2497 // The method set of PtrMutex's underlying type *Mutex remains unchanged,
2498 // but the method set of PtrMutex is empty.
2499 type PtrMutex *Mutex
2500
2501 // The method set of *PrintableMutex contains the methods
2502 // Lock and Unlock bound to its embedded field Mutex.
2503 type PrintableMutex struct {
2504         Mutex
2505 }
2506
2507 // MyBlock is an interface type that has the same method set as Block.
2508 type MyBlock Block
2509 </pre>
2510
2511 <p>
2512 Type definitions may be used to define different boolean, numeric,
2513 or string types and associate methods with them:
2514 </p>
2515
2516 <pre>
2517 type TimeZone int
2518
2519 const (
2520         EST TimeZone = -(5 + iota)
2521         CST
2522         MST
2523         PST
2524 )
2525
2526 func (tz TimeZone) String() string {
2527         return fmt.Sprintf("GMT%+dh", tz)
2528 }
2529 </pre>
2530
2531 <p>
2532 If the type definition specifies <a href="#Type_parameter_lists">type parameters</a>,
2533 the type name denotes a <i>parameterized type</i>.
2534 Parameterized types must be <a href="#Instantiations">instantiated</a> when they
2535 are used.
2536 </p>
2537
2538 <pre>
2539 type List[T any] struct {
2540         next  *List[T]
2541         value T
2542 }
2543
2544 type Tree[T constraints.Ordered] struct {
2545         left, right *Tree[T]
2546         value       T
2547 }
2548 </pre>
2549
2550 <p>
2551 The given type cannot be a type parameter in a type definition.
2552 </p>
2553
2554 <pre>
2555 type T[P any] P    // illegal: P is a type parameter
2556
2557 func f[T any]() {
2558         type L T   // illegal: T is a type parameter declared by the enclosing function
2559 }
2560 </pre>
2561
2562 <p>
2563 A parameterized type may also have methods associated with it. In this case,
2564 the method receivers must declare the same number of type parameters as
2565 present in the parameterized type definition.
2566 </p>
2567
2568 <pre>
2569 // The method Len returns the number of elements in the linked list l.
2570 func (l *List[T]) Len() int  { … }
2571 </pre>
2572
2573 <h3 id="Type_parameter_lists">Type parameter lists</h3>
2574
2575 <p>
2576 A type parameter list declares the <a href="#Type_parameters">type parameters</a>
2577 in a type-parameterized function or type declaration.
2578 The type parameter list looks like an ordinary <a href="#Function_types">function parameter list</a>
2579 except that the type parameter names must all be present and the list is enclosed
2580 in square brackets rather than parentheses.
2581 </p>
2582
2583 <pre class="ebnf">
2584 TypeParameters  = "[" TypeParamList [ "," ] "]" .
2585 TypeParamList   = TypeParamDecl { "," TypeParamDecl } .
2586 TypeParamDecl   = IdentifierList TypeConstraint .
2587 </pre>
2588
2589 <p>
2590 Each identifier declares a type parameter.
2591 All non-blank names in the list must be unique.
2592 Each type parameter is a new and different <a href="#Types">named type</a>.
2593 </p>
2594
2595 <pre>
2596 [P any]
2597 [S interface{ ~[]byte|string }]
2598 [S ~[]E, E any]
2599 [P Constraint[int]]
2600 [_ any]
2601 </pre>
2602
2603 <p>
2604 Just as each ordinary function parameter has a parameter type, each type parameter
2605 has a corresponding (meta-)type which is called its
2606 <a href="#Type_constraints"><i>type constraint</i></a>.
2607 </p>
2608
2609 <p>
2610 A parsing ambiguity arises when the type parameter list for a parameterized type
2611 declares a single type parameter with a type constraint of the form <code>*C</code>
2612 or <code>(C)</code> where <code>C</code> is not a (possibly parenthesized)
2613 <a href="#Types">type literal</a>:
2614 </p>
2615
2616 <pre>
2617 type T[P *C] …
2618 type T[P (C)] …
2619 </pre>
2620
2621 <p>
2622 In these rare cases, the type parameter declaration is indistinguishable from
2623 the expressions <code>P*C</code> or <code>P(C)</code> and the type declaration
2624 is parsed as an array type declaration.
2625 To resolve the ambiguity, embed the constraint in an interface or use a trailing
2626 comma:
2627 </p>
2628
2629 <pre>
2630 type T[P interface{*C}] …
2631 type T[P *C,] …
2632 </pre>
2633
2634 <h4 id="Type_constraints">Type constraints</h4>
2635
2636 <p>
2637 A type constraint is an <a href="#Interface_types">interface</a> that defines the
2638 set of permissible type arguments for the respective type parameter and controls the
2639 operations supported by values of that type parameter.
2640 </p>
2641
2642 <pre class="ebnf">
2643 TypeConstraint = TypeElem .
2644 </pre>
2645
2646 <p>
2647 If the constraint is an interface literal containing exactly one embedded type element
2648 <code>interface{E}</code>, in a type parameter list the enclosing <code>interface{ … }</code>
2649 may be omitted for convenience:
2650 </p>
2651
2652 <pre>
2653 [T *P]                             // = [T interface{*P}]
2654 [T ~int]                           // = [T interface{~int}]
2655 [T int|string]                     // = [T interface{int|string}]
2656 type Constraint ~int               // illegal: ~int is not inside a type parameter list
2657 </pre>
2658
2659 <!--
2660 We should be able to simplify the rules for comparable or delegate some of them
2661 elsewhere once we have a section that clearly defines how interfaces implement
2662 other interfaces based on their type sets. But this should get us going for now.
2663 -->
2664
2665 <p>
2666 The <a href="#Predeclared_identifiers">predeclared</a>
2667 <a href="#Interface_types">interface type</a> <code>comparable</code>
2668 denotes the set of all concrete (non-interface) types that are
2669 <a href="#Comparison_operators">comparable</a>. Specifically,
2670 a type <code>T</code> implements <code>comparable</code> if:
2671 </p>
2672
2673 <ul>
2674 <li>
2675         <code>T</code> is not an interface type and <code>T</code> supports the operations
2676         <code>==</code> and <code>!=</code>; or
2677 </li>
2678 <li>
2679         <code>T</code> is an interface type and each type in <code>T</code>'s
2680         <a href="#Interface_types">type set</a> implements <code>comparable</code>.
2681 </li>
2682 </ul>
2683
2684 <p>
2685 Even though interfaces that are not type parameters can be
2686 <a href="#Comparison_operators">compared</a>
2687 (possibly causing a run-time panic) they do not implement
2688 <code>comparable</code>.
2689 </p>
2690
2691 <pre>
2692 int                          // implements comparable
2693 []byte                       // does not implement comparable (slices cannot be compared)
2694 interface{}                  // does not implement comparable (see above)
2695 interface{ ~int | ~string }  // type parameter only: implements comparable
2696 interface{ comparable }      // type parameter only: implements comparable
2697 interface{ ~int | ~[]byte }  // type parameter only: does not implement comparable (not all types in the type set are comparable)
2698 </pre>
2699
2700 <p>
2701 The <code>comparable</code> interface and interfaces that (directly or indirectly) embed
2702 <code>comparable</code> may only be used as type constraints. They cannot be the types of
2703 values or variables, or components of other, non-interface types.
2704 </p>
2705
2706 <h3 id="Variable_declarations">Variable declarations</h3>
2707
2708 <p>
2709 A variable declaration creates one or more <a href="#Variables">variables</a>,
2710 binds corresponding identifiers to them, and gives each a type and an initial value.
2711 </p>
2712
2713 <pre class="ebnf">
2714 VarDecl     = "var" ( VarSpec | "(" { VarSpec ";" } ")" ) .
2715 VarSpec     = IdentifierList ( Type [ "=" ExpressionList ] | "=" ExpressionList ) .
2716 </pre>
2717
2718 <pre>
2719 var i int
2720 var U, V, W float64
2721 var k = 0
2722 var x, y float32 = -1, -2
2723 var (
2724         i       int
2725         u, v, s = 2.0, 3.0, "bar"
2726 )
2727 var re, im = complexSqrt(-1)
2728 var _, found = entries[name]  // map lookup; only interested in "found"
2729 </pre>
2730
2731 <p>
2732 If a list of expressions is given, the variables are initialized
2733 with the expressions following the rules for <a href="#Assignments">assignments</a>.
2734 Otherwise, each variable is initialized to its <a href="#The_zero_value">zero value</a>.
2735 </p>
2736
2737 <p>
2738 If a type is present, each variable is given that type.
2739 Otherwise, each variable is given the type of the corresponding
2740 initialization value in the assignment.
2741 If that value is an untyped constant, it is first implicitly
2742 <a href="#Conversions">converted</a> to its <a href="#Constants">default type</a>;
2743 if it is an untyped boolean value, it is first implicitly converted to type <code>bool</code>.
2744 The predeclared value <code>nil</code> cannot be used to initialize a variable
2745 with no explicit type.
2746 </p>
2747
2748 <pre>
2749 var d = math.Sin(0.5)  // d is float64
2750 var i = 42             // i is int
2751 var t, ok = x.(T)      // t is T, ok is bool
2752 var n = nil            // illegal
2753 </pre>
2754
2755 <p>
2756 Implementation restriction: A compiler may make it illegal to declare a variable
2757 inside a <a href="#Function_declarations">function body</a> if the variable is
2758 never used.
2759 </p>
2760
2761 <h3 id="Short_variable_declarations">Short variable declarations</h3>
2762
2763 <p>
2764 A <i>short variable declaration</i> uses the syntax:
2765 </p>
2766
2767 <pre class="ebnf">
2768 ShortVarDecl = IdentifierList ":=" ExpressionList .
2769 </pre>
2770
2771 <p>
2772 It is shorthand for a regular <a href="#Variable_declarations">variable declaration</a>
2773 with initializer expressions but no types:
2774 </p>
2775
2776 <pre class="grammar">
2777 "var" IdentifierList = ExpressionList .
2778 </pre>
2779
2780 <pre>
2781 i, j := 0, 10
2782 f := func() int { return 7 }
2783 ch := make(chan int)
2784 r, w, _ := os.Pipe()  // os.Pipe() returns a connected pair of Files and an error, if any
2785 _, y, _ := coord(p)   // coord() returns three values; only interested in y coordinate
2786 </pre>
2787
2788 <p>
2789 Unlike regular variable declarations, a short variable declaration may <i>redeclare</i>
2790 variables provided they were originally declared earlier in the same block
2791 (or the parameter lists if the block is the function body) with the same type,
2792 and at least one of the non-<a href="#Blank_identifier">blank</a> variables is new.
2793 As a consequence, redeclaration can only appear in a multi-variable short declaration.
2794 Redeclaration does not introduce a new variable; it just assigns a new value to the original.
2795 </p>
2796
2797 <pre>
2798 field1, offset := nextField(str, 0)
2799 field2, offset := nextField(str, offset)  // redeclares offset
2800 a, a := 1, 2                              // illegal: double declaration of a or no new variable if a was declared elsewhere
2801 </pre>
2802
2803 <p>
2804 Short variable declarations may appear only inside functions.
2805 In some contexts such as the initializers for
2806 <a href="#If_statements">"if"</a>,
2807 <a href="#For_statements">"for"</a>, or
2808 <a href="#Switch_statements">"switch"</a> statements,
2809 they can be used to declare local temporary variables.
2810 </p>
2811
2812 <h3 id="Function_declarations">Function declarations</h3>
2813
2814 <!--
2815         Given the importance of functions, this section has always
2816         been woefully underdeveloped. Would be nice to expand this
2817         a bit.
2818 -->
2819
2820 <p>
2821 A function declaration binds an identifier, the <i>function name</i>,
2822 to a function.
2823 </p>
2824
2825 <pre class="ebnf">
2826 FunctionDecl = "func" FunctionName [ TypeParameters ] Signature [ FunctionBody ] .
2827 FunctionName = identifier .
2828 FunctionBody = Block .
2829 </pre>
2830
2831 <p>
2832 If the function's <a href="#Function_types">signature</a> declares
2833 result parameters, the function body's statement list must end in
2834 a <a href="#Terminating_statements">terminating statement</a>.
2835 </p>
2836
2837 <pre>
2838 func IndexRune(s string, r rune) int {
2839         for i, c := range s {
2840                 if c == r {
2841                         return i
2842                 }
2843         }
2844         // invalid: missing return statement
2845 }
2846 </pre>
2847
2848 <p>
2849 If the function declaration specifies <a href="#Type_parameter_lists">type parameters</a>,
2850 the function name denotes a <i>type-parameterized function</i>.
2851 Type-parameterized functions must be <a href="#Instantiations">instantiated</a> when they
2852 are used.
2853 </p>
2854
2855 <pre>
2856 func min[T constraints.Ordered](x, y T) T {
2857         if x &lt; y {
2858                 return x
2859         }
2860         return y
2861 }
2862 </pre>
2863
2864 <p>
2865 A function declaration without type parameters may omit the body.
2866 Such a declaration provides the signature for a function implemented outside Go,
2867 such as an assembly routine.
2868 </p>
2869
2870 <pre>
2871 func flushICache(begin, end uintptr)  // implemented externally
2872 </pre>
2873
2874 <h3 id="Method_declarations">Method declarations</h3>
2875
2876 <p>
2877 A method is a <a href="#Function_declarations">function</a> with a <i>receiver</i>.
2878 A method declaration binds an identifier, the <i>method name</i>, to a method,
2879 and associates the method with the receiver's <i>base type</i>.
2880 </p>
2881
2882 <pre class="ebnf">
2883 MethodDecl = "func" Receiver MethodName Signature [ FunctionBody ] .
2884 Receiver   = Parameters .
2885 </pre>
2886
2887 <p>
2888 The receiver is specified via an extra parameter section preceding the method
2889 name. That parameter section must declare a single non-variadic parameter, the receiver.
2890 Its type must be a <a href="#Type_definitions">defined</a> type <code>T</code> or a
2891 pointer to a defined type <code>T</code>, possibly followed by a list of type parameter
2892 names <code>[P1, P2, …]</code> enclosed in square brackets.
2893 <code>T</code> is called the receiver <i>base type</i>. A receiver base type cannot be
2894 a pointer or interface type and it must be defined in the same package as the method.
2895 The method is said to be <i>bound</i> to its receiver base type and the method name
2896 is visible only within <a href="#Selectors">selectors</a> for type <code>T</code>
2897 or <code>*T</code>.
2898 </p>
2899
2900 <p>
2901 A non-<a href="#Blank_identifier">blank</a> receiver identifier must be
2902 <a href="#Uniqueness_of_identifiers">unique</a> in the method signature.
2903 If the receiver's value is not referenced inside the body of the method,
2904 its identifier may be omitted in the declaration. The same applies in
2905 general to parameters of functions and methods.
2906 </p>
2907
2908 <p>
2909 For a base type, the non-blank names of methods bound to it must be unique.
2910 If the base type is a <a href="#Struct_types">struct type</a>,
2911 the non-blank method and field names must be distinct.
2912 </p>
2913
2914 <p>
2915 Given defined type <code>Point</code>, the declarations
2916 </p>
2917
2918 <pre>
2919 func (p *Point) Length() float64 {
2920         return math.Sqrt(p.x * p.x + p.y * p.y)
2921 }
2922
2923 func (p *Point) Scale(factor float64) {
2924         p.x *= factor
2925         p.y *= factor
2926 }
2927 </pre>
2928
2929 <p>
2930 bind the methods <code>Length</code> and <code>Scale</code>,
2931 with receiver type <code>*Point</code>,
2932 to the base type <code>Point</code>.
2933 </p>
2934
2935 <p>
2936 If the receiver base type is a <a href="#Type_declarations">parameterized type</a>, the
2937 receiver specification must declare corresponding type parameters for the method
2938 to use. This makes the receiver type parameters available to the method.
2939 </p>
2940
2941 <p>
2942 Syntactically, this type parameter declaration looks like an
2943 <a href="#Instantiations">instantiation</a> of the receiver base type, except that
2944 the type arguments are the type parameters being declared, one for each type parameter
2945 of the receiver base type.
2946 The type parameter names do not need to match their corresponding parameter names in the
2947 receiver base type definition, and all non-blank parameter names must be unique in the
2948 receiver parameter section and the method signature.
2949 The receiver type parameter constraints are implied by the receiver base type definition:
2950 corresponding type parameters have corresponding constraints.
2951 </p>
2952
2953 <pre>
2954 type Pair[A, B any] struct {
2955         a A
2956         b B
2957 }
2958
2959 func (p Pair[A, B]) Swap() Pair[B, A]  { return Pair[B, A]{p.b, p.a} }
2960 func (p Pair[First, _]) First() First  { return p.a }
2961 </pre>
2962
2963 <h2 id="Expressions">Expressions</h2>
2964
2965 <p>
2966 An expression specifies the computation of a value by applying
2967 operators and functions to operands.
2968 </p>
2969
2970 <h3 id="Operands">Operands</h3>
2971
2972 <p>
2973 Operands denote the elementary values in an expression. An operand may be a
2974 literal, a (possibly <a href="#Qualified_identifiers">qualified</a>)
2975 non-<a href="#Blank_identifier">blank</a> identifier denoting a
2976 <a href="#Constant_declarations">constant</a>,
2977 <a href="#Variable_declarations">variable</a>, or
2978 <a href="#Function_declarations">function</a>,
2979 or a parenthesized expression.
2980 </p>
2981
2982 <p>
2983 An operand name denoting a <a href="#Function_declarations">type-parameterized function</a>
2984 may be followed by a list of <a href="#Instantiations">type arguments</a>; the
2985 resulting operand is an <a href="#Instantiations">instantiated</a> function.
2986 </p>
2987
2988 <p>
2989 The <a href="#Blank_identifier">blank identifier</a> may appear as an
2990 operand only on the left-hand side of an <a href="#Assignments">assignment</a>.
2991 </p>
2992
2993 <pre class="ebnf">
2994 Operand     = Literal | OperandName [ TypeArgs ] | "(" Expression ")" .
2995 Literal     = BasicLit | CompositeLit | FunctionLit .
2996 BasicLit    = int_lit | float_lit | imaginary_lit | rune_lit | string_lit .
2997 OperandName = identifier | QualifiedIdent .
2998 </pre>
2999
3000 <h3 id="Qualified_identifiers">Qualified identifiers</h3>
3001
3002 <p>
3003 A <i>qualified identifier</i> is an identifier qualified with a package name prefix.
3004 Both the package name and the identifier must not be
3005 <a href="#Blank_identifier">blank</a>.
3006 </p>
3007
3008 <pre class="ebnf">
3009 QualifiedIdent = PackageName "." identifier .
3010 </pre>
3011
3012 <p>
3013 A qualified identifier accesses an identifier in a different package, which
3014 must be <a href="#Import_declarations">imported</a>.
3015 The identifier must be <a href="#Exported_identifiers">exported</a> and
3016 declared in the <a href="#Blocks">package block</a> of that package.
3017 </p>
3018
3019 <pre>
3020 math.Sin        // denotes the Sin function in package math
3021 </pre>
3022
3023 <h3 id="Composite_literals">Composite literals</h3>
3024
3025 <p>
3026 Composite literals construct values for structs, arrays, slices, and maps
3027 and create a new value each time they are evaluated.
3028 They consist of the type of the literal followed by a brace-bound list of elements.
3029 Each element may optionally be preceded by a corresponding key.
3030 </p>
3031
3032 <pre class="ebnf">
3033 CompositeLit  = LiteralType LiteralValue .
3034 LiteralType   = StructType | ArrayType | "[" "..." "]" ElementType |
3035                 SliceType | MapType | TypeName .
3036 LiteralValue  = "{" [ ElementList [ "," ] ] "}" .
3037 ElementList   = KeyedElement { "," KeyedElement } .
3038 KeyedElement  = [ Key ":" ] Element .
3039 Key           = FieldName | Expression | LiteralValue .
3040 FieldName     = identifier .
3041 Element       = Expression | LiteralValue .
3042 </pre>
3043
3044 <p>
3045 The LiteralType's underlying type must be a struct, array, slice, or map type
3046 (the grammar enforces this constraint except when the type is given
3047 as a TypeName).
3048 The types of the elements and keys must be <a href="#Assignability">assignable</a>
3049 to the respective field, element, and key types of the literal type;
3050 there is no additional conversion.
3051 The key is interpreted as a field name for struct literals,
3052 an index for array and slice literals, and a key for map literals.
3053 For map literals, all elements must have a key. It is an error
3054 to specify multiple elements with the same field name or
3055 constant key value. For non-constant map keys, see the section on
3056 <a href="#Order_of_evaluation">evaluation order</a>.
3057 </p>
3058
3059 <p>
3060 For struct literals the following rules apply:
3061 </p>
3062 <ul>
3063         <li>A key must be a field name declared in the struct type.
3064         </li>
3065         <li>An element list that does not contain any keys must
3066             list an element for each struct field in the
3067             order in which the fields are declared.
3068         </li>
3069         <li>If any element has a key, every element must have a key.
3070         </li>
3071         <li>An element list that contains keys does not need to
3072             have an element for each struct field. Omitted fields
3073             get the zero value for that field.
3074         </li>
3075         <li>A literal may omit the element list; such a literal evaluates
3076             to the zero value for its type.
3077         </li>
3078         <li>It is an error to specify an element for a non-exported
3079             field of a struct belonging to a different package.
3080         </li>
3081 </ul>
3082
3083 <p>
3084 Given the declarations
3085 </p>
3086 <pre>
3087 type Point3D struct { x, y, z float64 }
3088 type Line struct { p, q Point3D }
3089 </pre>
3090
3091 <p>
3092 one may write
3093 </p>
3094
3095 <pre>
3096 origin := Point3D{}                            // zero value for Point3D
3097 line := Line{origin, Point3D{y: -4, z: 12.3}}  // zero value for line.q.x
3098 </pre>
3099
3100 <p>
3101 For array and slice literals the following rules apply:
3102 </p>
3103 <ul>
3104         <li>Each element has an associated integer index marking
3105             its position in the array.
3106         </li>
3107         <li>An element with a key uses the key as its index. The
3108             key must be a non-negative constant
3109             <a href="#Representability">representable</a> by
3110             a value of type <code>int</code>; and if it is typed
3111             it must be of integer type.
3112         </li>
3113         <li>An element without a key uses the previous element's index plus one.
3114             If the first element has no key, its index is zero.
3115         </li>
3116 </ul>
3117
3118 <p>
3119 <a href="#Address_operators">Taking the address</a> of a composite literal
3120 generates a pointer to a unique <a href="#Variables">variable</a> initialized
3121 with the literal's value.
3122 </p>
3123
3124 <pre>
3125 var pointer *Point3D = &amp;Point3D{y: 1000}
3126 </pre>
3127
3128 <p>
3129 Note that the <a href="#The_zero_value">zero value</a> for a slice or map
3130 type is not the same as an initialized but empty value of the same type.
3131 Consequently, taking the address of an empty slice or map composite literal
3132 does not have the same effect as allocating a new slice or map value with
3133 <a href="#Allocation">new</a>.
3134 </p>
3135
3136 <pre>
3137 p1 := &amp;[]int{}    // p1 points to an initialized, empty slice with value []int{} and length 0
3138 p2 := new([]int)  // p2 points to an uninitialized slice with value nil and length 0
3139 </pre>
3140
3141 <p>
3142 The length of an array literal is the length specified in the literal type.
3143 If fewer elements than the length are provided in the literal, the missing
3144 elements are set to the zero value for the array element type.
3145 It is an error to provide elements with index values outside the index range
3146 of the array. The notation <code>...</code> specifies an array length equal
3147 to the maximum element index plus one.
3148 </p>
3149
3150 <pre>
3151 buffer := [10]string{}             // len(buffer) == 10
3152 intSet := [6]int{1, 2, 3, 5}       // len(intSet) == 6
3153 days := [...]string{"Sat", "Sun"}  // len(days) == 2
3154 </pre>
3155
3156 <p>
3157 A slice literal describes the entire underlying array literal.
3158 Thus the length and capacity of a slice literal are the maximum
3159 element index plus one. A slice literal has the form
3160 </p>
3161
3162 <pre>
3163 []T{x1, x2, … xn}
3164 </pre>
3165
3166 <p>
3167 and is shorthand for a slice operation applied to an array:
3168 </p>
3169
3170 <pre>
3171 tmp := [n]T{x1, x2, … xn}
3172 tmp[0 : n]
3173 </pre>
3174
3175 <p>
3176 Within a composite literal of array, slice, or map type <code>T</code>,
3177 elements or map keys that are themselves composite literals may elide the respective
3178 literal type if it is identical to the element or key type of <code>T</code>.
3179 Similarly, elements or keys that are addresses of composite literals may elide
3180 the <code>&amp;T</code> when the element or key type is <code>*T</code>.
3181 </p>
3182
3183 <pre>
3184 [...]Point{{1.5, -3.5}, {0, 0}}     // same as [...]Point{Point{1.5, -3.5}, Point{0, 0}}
3185 [][]int{{1, 2, 3}, {4, 5}}          // same as [][]int{[]int{1, 2, 3}, []int{4, 5}}
3186 [][]Point{{{0, 1}, {1, 2}}}         // same as [][]Point{[]Point{Point{0, 1}, Point{1, 2}}}
3187 map[string]Point{"orig": {0, 0}}    // same as map[string]Point{"orig": Point{0, 0}}
3188 map[Point]string{{0, 0}: "orig"}    // same as map[Point]string{Point{0, 0}: "orig"}
3189
3190 type PPoint *Point
3191 [2]*Point{{1.5, -3.5}, {}}          // same as [2]*Point{&amp;Point{1.5, -3.5}, &amp;Point{}}
3192 [2]PPoint{{1.5, -3.5}, {}}          // same as [2]PPoint{PPoint(&amp;Point{1.5, -3.5}), PPoint(&amp;Point{})}
3193 </pre>
3194
3195 <p>
3196 A parsing ambiguity arises when a composite literal using the
3197 TypeName form of the LiteralType appears as an operand between the
3198 <a href="#Keywords">keyword</a> and the opening brace of the block
3199 of an "if", "for", or "switch" statement, and the composite literal
3200 is not enclosed in parentheses, square brackets, or curly braces.
3201 In this rare case, the opening brace of the literal is erroneously parsed
3202 as the one introducing the block of statements. To resolve the ambiguity,
3203 the composite literal must appear within parentheses.
3204 </p>
3205
3206 <pre>
3207 if x == (T{a,b,c}[i]) { … }
3208 if (x == T{a,b,c}[i]) { … }
3209 </pre>
3210
3211 <p>
3212 Examples of valid array, slice, and map literals:
3213 </p>
3214
3215 <pre>
3216 // list of prime numbers
3217 primes := []int{2, 3, 5, 7, 9, 2147483647}
3218
3219 // vowels[ch] is true if ch is a vowel
3220 vowels := [128]bool{'a': true, 'e': true, 'i': true, 'o': true, 'u': true, 'y': true}
3221
3222 // the array [10]float32{-1, 0, 0, 0, -0.1, -0.1, 0, 0, 0, -1}
3223 filter := [10]float32{-1, 4: -0.1, -0.1, 9: -1}
3224
3225 // frequencies in Hz for equal-tempered scale (A4 = 440Hz)
3226 noteFrequency := map[string]float32{
3227         "C0": 16.35, "D0": 18.35, "E0": 20.60, "F0": 21.83,
3228         "G0": 24.50, "A0": 27.50, "B0": 30.87,
3229 }
3230 </pre>
3231
3232
3233 <h3 id="Function_literals">Function literals</h3>
3234
3235 <p>
3236 A function literal represents an anonymous <a href="#Function_declarations">function</a>.
3237 Function literals cannot declare type parameters.
3238 </p>
3239
3240 <pre class="ebnf">
3241 FunctionLit = "func" Signature FunctionBody .
3242 </pre>
3243
3244 <pre>
3245 func(a, b int, z float64) bool { return a*b &lt; int(z) }
3246 </pre>
3247
3248 <p>
3249 A function literal can be assigned to a variable or invoked directly.
3250 </p>
3251
3252 <pre>
3253 f := func(x, y int) int { return x + y }
3254 func(ch chan int) { ch &lt;- ACK }(replyChan)
3255 </pre>
3256
3257 <p>
3258 Function literals are <i>closures</i>: they may refer to variables
3259 defined in a surrounding function. Those variables are then shared between
3260 the surrounding function and the function literal, and they survive as long
3261 as they are accessible.
3262 </p>
3263
3264
3265 <h3 id="Primary_expressions">Primary expressions</h3>
3266
3267 <p>
3268 Primary expressions are the operands for unary and binary expressions.
3269 </p>
3270
3271 <pre class="ebnf">
3272 PrimaryExpr =
3273         Operand |
3274         Conversion |
3275         MethodExpr |
3276         PrimaryExpr Selector |
3277         PrimaryExpr Index |
3278         PrimaryExpr Slice |
3279         PrimaryExpr TypeAssertion |
3280         PrimaryExpr Arguments .
3281
3282 Selector       = "." identifier .
3283 Index          = "[" Expression "]" .
3284 Slice          = "[" [ Expression ] ":" [ Expression ] "]" |
3285                  "[" [ Expression ] ":" Expression ":" Expression "]" .
3286 TypeAssertion  = "." "(" Type ")" .
3287 Arguments      = "(" [ ( ExpressionList | Type [ "," ExpressionList ] ) [ "..." ] [ "," ] ] ")" .
3288 </pre>
3289
3290
3291 <pre>
3292 x
3293 2
3294 (s + ".txt")
3295 f(3.1415, true)
3296 Point{1, 2}
3297 m["foo"]
3298 s[i : j + 1]
3299 obj.color
3300 f.p[i].x()
3301 </pre>
3302
3303
3304 <h3 id="Selectors">Selectors</h3>
3305
3306 <p>
3307 For a <a href="#Primary_expressions">primary expression</a> <code>x</code>
3308 that is not a <a href="#Package_clause">package name</a>, the
3309 <i>selector expression</i>
3310 </p>
3311
3312 <pre>
3313 x.f
3314 </pre>
3315
3316 <p>
3317 denotes the field or method <code>f</code> of the value <code>x</code>
3318 (or sometimes <code>*x</code>; see below).
3319 The identifier <code>f</code> is called the (field or method) <i>selector</i>;
3320 it must not be the <a href="#Blank_identifier">blank identifier</a>.
3321 The type of the selector expression is the type of <code>f</code>.
3322 If <code>x</code> is a package name, see the section on
3323 <a href="#Qualified_identifiers">qualified identifiers</a>.
3324 </p>
3325
3326 <p>
3327 A selector <code>f</code> may denote a field or method <code>f</code> of
3328 a type <code>T</code>, or it may refer
3329 to a field or method <code>f</code> of a nested
3330 <a href="#Struct_types">embedded field</a> of <code>T</code>.
3331 The number of embedded fields traversed
3332 to reach <code>f</code> is called its <i>depth</i> in <code>T</code>.
3333 The depth of a field or method <code>f</code>
3334 declared in <code>T</code> is zero.
3335 The depth of a field or method <code>f</code> declared in
3336 an embedded field <code>A</code> in <code>T</code> is the
3337 depth of <code>f</code> in <code>A</code> plus one.
3338 </p>
3339
3340 <p>
3341 The following rules apply to selectors:
3342 </p>
3343
3344 <ol>
3345 <li>
3346 For a value <code>x</code> of type <code>T</code> or <code>*T</code>
3347 where <code>T</code> is not a pointer or interface type,
3348 <code>x.f</code> denotes the field or method at the shallowest depth
3349 in <code>T</code> where there
3350 is such an <code>f</code>.
3351 If there is not exactly <a href="#Uniqueness_of_identifiers">one <code>f</code></a>
3352 with shallowest depth, the selector expression is illegal.
3353 </li>
3354
3355 <li>
3356 For a value <code>x</code> of type <code>I</code> where <code>I</code>
3357 is an interface type, <code>x.f</code> denotes the actual method with name
3358 <code>f</code> of the dynamic value of <code>x</code>.
3359 If there is no method with name <code>f</code> in the
3360 <a href="#Method_sets">method set</a> of <code>I</code>, the selector
3361 expression is illegal.
3362 </li>
3363
3364 <li>
3365 As an exception, if the type of <code>x</code> is a <a href="#Type_definitions">defined</a>
3366 pointer type and <code>(*x).f</code> is a valid selector expression denoting a field
3367 (but not a method), <code>x.f</code> is shorthand for <code>(*x).f</code>.
3368 </li>
3369
3370 <li>
3371 In all other cases, <code>x.f</code> is illegal.
3372 </li>
3373
3374 <li>
3375 If <code>x</code> is of pointer type and has the value
3376 <code>nil</code> and <code>x.f</code> denotes a struct field,
3377 assigning to or evaluating <code>x.f</code>
3378 causes a <a href="#Run_time_panics">run-time panic</a>.
3379 </li>
3380
3381 <li>
3382 If <code>x</code> is of interface type and has the value
3383 <code>nil</code>, <a href="#Calls">calling</a> or
3384 <a href="#Method_values">evaluating</a> the method <code>x.f</code>
3385 causes a <a href="#Run_time_panics">run-time panic</a>.
3386 </li>
3387 </ol>
3388
3389 <p>
3390 For example, given the declarations:
3391 </p>
3392
3393 <pre>
3394 type T0 struct {
3395         x int
3396 }
3397
3398 func (*T0) M0()
3399
3400 type T1 struct {
3401         y int
3402 }
3403
3404 func (T1) M1()
3405
3406 type T2 struct {
3407         z int
3408         T1
3409         *T0
3410 }
3411
3412 func (*T2) M2()
3413
3414 type Q *T2
3415
3416 var t T2     // with t.T0 != nil
3417 var p *T2    // with p != nil and (*p).T0 != nil
3418 var q Q = p
3419 </pre>
3420
3421 <p>
3422 one may write:
3423 </p>
3424
3425 <pre>
3426 t.z          // t.z
3427 t.y          // t.T1.y
3428 t.x          // (*t.T0).x
3429
3430 p.z          // (*p).z
3431 p.y          // (*p).T1.y
3432 p.x          // (*(*p).T0).x
3433
3434 q.x          // (*(*q).T0).x        (*q).x is a valid field selector
3435
3436 p.M0()       // ((*p).T0).M0()      M0 expects *T0 receiver
3437 p.M1()       // ((*p).T1).M1()      M1 expects T1 receiver
3438 p.M2()       // p.M2()              M2 expects *T2 receiver
3439 t.M2()       // (&amp;t).M2()           M2 expects *T2 receiver, see section on Calls
3440 </pre>
3441
3442 <p>
3443 but the following is invalid:
3444 </p>
3445
3446 <pre>
3447 q.M0()       // (*q).M0 is valid but not a field selector
3448 </pre>
3449
3450
3451 <h3 id="Method_expressions">Method expressions</h3>
3452
3453 <p>
3454 If <code>M</code> is in the <a href="#Method_sets">method set</a> of type <code>T</code>,
3455 <code>T.M</code> is a function that is callable as a regular function
3456 with the same arguments as <code>M</code> prefixed by an additional
3457 argument that is the receiver of the method.
3458 </p>
3459
3460 <pre class="ebnf">
3461 MethodExpr    = ReceiverType "." MethodName .
3462 ReceiverType  = Type .
3463 </pre>
3464
3465 <p>
3466 Consider a struct type <code>T</code> with two methods,
3467 <code>Mv</code>, whose receiver is of type <code>T</code>, and
3468 <code>Mp</code>, whose receiver is of type <code>*T</code>.
3469 </p>
3470
3471 <pre>
3472 type T struct {
3473         a int
3474 }
3475 func (tv  T) Mv(a int) int         { return 0 }  // value receiver
3476 func (tp *T) Mp(f float32) float32 { return 1 }  // pointer receiver
3477
3478 var t T
3479 </pre>
3480
3481 <p>
3482 The expression
3483 </p>
3484
3485 <pre>
3486 T.Mv
3487 </pre>
3488
3489 <p>
3490 yields a function equivalent to <code>Mv</code> but
3491 with an explicit receiver as its first argument; it has signature
3492 </p>
3493
3494 <pre>
3495 func(tv T, a int) int
3496 </pre>
3497
3498 <p>
3499 That function may be called normally with an explicit receiver, so
3500 these five invocations are equivalent:
3501 </p>
3502
3503 <pre>
3504 t.Mv(7)
3505 T.Mv(t, 7)
3506 (T).Mv(t, 7)
3507 f1 := T.Mv; f1(t, 7)
3508 f2 := (T).Mv; f2(t, 7)
3509 </pre>
3510
3511 <p>
3512 Similarly, the expression
3513 </p>
3514
3515 <pre>
3516 (*T).Mp
3517 </pre>
3518
3519 <p>
3520 yields a function value representing <code>Mp</code> with signature
3521 </p>
3522
3523 <pre>
3524 func(tp *T, f float32) float32
3525 </pre>
3526
3527 <p>
3528 For a method with a value receiver, one can derive a function
3529 with an explicit pointer receiver, so
3530 </p>
3531
3532 <pre>
3533 (*T).Mv
3534 </pre>
3535
3536 <p>
3537 yields a function value representing <code>Mv</code> with signature
3538 </p>
3539
3540 <pre>
3541 func(tv *T, a int) int
3542 </pre>
3543
3544 <p>
3545 Such a function indirects through the receiver to create a value
3546 to pass as the receiver to the underlying method;
3547 the method does not overwrite the value whose address is passed in
3548 the function call.
3549 </p>
3550
3551 <p>
3552 The final case, a value-receiver function for a pointer-receiver method,
3553 is illegal because pointer-receiver methods are not in the method set
3554 of the value type.
3555 </p>
3556
3557 <p>
3558 Function values derived from methods are called with function call syntax;
3559 the receiver is provided as the first argument to the call.
3560 That is, given <code>f := T.Mv</code>, <code>f</code> is invoked
3561 as <code>f(t, 7)</code> not <code>t.f(7)</code>.
3562 To construct a function that binds the receiver, use a
3563 <a href="#Function_literals">function literal</a> or
3564 <a href="#Method_values">method value</a>.
3565 </p>
3566
3567 <p>
3568 It is legal to derive a function value from a method of an interface type.
3569 The resulting function takes an explicit receiver of that interface type.
3570 </p>
3571
3572 <h3 id="Method_values">Method values</h3>
3573
3574 <p>
3575 If the expression <code>x</code> has static type <code>T</code> and
3576 <code>M</code> is in the <a href="#Method_sets">method set</a> of type <code>T</code>,
3577 <code>x.M</code> is called a <i>method value</i>.
3578 The method value <code>x.M</code> is a function value that is callable
3579 with the same arguments as a method call of <code>x.M</code>.
3580 The expression <code>x</code> is evaluated and saved during the evaluation of the
3581 method value; the saved copy is then used as the receiver in any calls,
3582 which may be executed later.
3583 </p>
3584
3585 <pre>
3586 type S struct { *T }
3587 type T int
3588 func (t T) M() { print(t) }
3589
3590 t := new(T)
3591 s := S{T: t}
3592 f := t.M                    // receiver *t is evaluated and stored in f
3593 g := s.M                    // receiver *(s.T) is evaluated and stored in g
3594 *t = 42                     // does not affect stored receivers in f and g
3595 </pre>
3596
3597 <p>
3598 The type <code>T</code> may be an interface or non-interface type.
3599 </p>
3600
3601 <p>
3602 As in the discussion of <a href="#Method_expressions">method expressions</a> above,
3603 consider a struct type <code>T</code> with two methods,
3604 <code>Mv</code>, whose receiver is of type <code>T</code>, and
3605 <code>Mp</code>, whose receiver is of type <code>*T</code>.
3606 </p>
3607
3608 <pre>
3609 type T struct {
3610         a int
3611 }
3612 func (tv  T) Mv(a int) int         { return 0 }  // value receiver
3613 func (tp *T) Mp(f float32) float32 { return 1 }  // pointer receiver
3614
3615 var t T
3616 var pt *T
3617 func makeT() T
3618 </pre>
3619
3620 <p>
3621 The expression
3622 </p>
3623
3624 <pre>
3625 t.Mv
3626 </pre>
3627
3628 <p>
3629 yields a function value of type
3630 </p>
3631
3632 <pre>
3633 func(int) int
3634 </pre>
3635
3636 <p>
3637 These two invocations are equivalent:
3638 </p>
3639
3640 <pre>
3641 t.Mv(7)
3642 f := t.Mv; f(7)
3643 </pre>
3644
3645 <p>
3646 Similarly, the expression
3647 </p>
3648
3649 <pre>
3650 pt.Mp
3651 </pre>
3652
3653 <p>
3654 yields a function value of type
3655 </p>
3656
3657 <pre>
3658 func(float32) float32
3659 </pre>
3660
3661 <p>
3662 As with <a href="#Selectors">selectors</a>, a reference to a non-interface method with a value receiver
3663 using a pointer will automatically dereference that pointer: <code>pt.Mv</code> is equivalent to <code>(*pt).Mv</code>.
3664 </p>
3665
3666 <p>
3667 As with <a href="#Calls">method calls</a>, a reference to a non-interface method with a pointer receiver
3668 using an addressable value will automatically take the address of that value: <code>t.Mp</code> is equivalent to <code>(&amp;t).Mp</code>.
3669 </p>
3670
3671 <pre>
3672 f := t.Mv; f(7)   // like t.Mv(7)
3673 f := pt.Mp; f(7)  // like pt.Mp(7)
3674 f := pt.Mv; f(7)  // like (*pt).Mv(7)
3675 f := t.Mp; f(7)   // like (&amp;t).Mp(7)
3676 f := makeT().Mp   // invalid: result of makeT() is not addressable
3677 </pre>
3678
3679 <p>
3680 Although the examples above use non-interface types, it is also legal to create a method value
3681 from a value of interface type.
3682 </p>
3683
3684 <pre>
3685 var i interface { M(int) } = myVal
3686 f := i.M; f(7)  // like i.M(7)
3687 </pre>
3688
3689
3690 <h3 id="Index_expressions">Index expressions</h3>
3691
3692 <p>
3693 A primary expression of the form
3694 </p>
3695
3696 <pre>
3697 a[x]
3698 </pre>
3699
3700 <p>
3701 denotes the element of the array, pointer to array, slice, string or map <code>a</code> indexed by <code>x</code>.
3702 The value <code>x</code> is called the <i>index</i> or <i>map key</i>, respectively.
3703 The following rules apply:
3704 </p>
3705
3706 <p>
3707 If <code>a</code> is not a map:
3708 </p>
3709 <ul>
3710         <li>the index <code>x</code> must be of integer type or an untyped constant</li>
3711         <li>a constant index must be non-negative and
3712             <a href="#Representability">representable</a> by a value of type <code>int</code></li>
3713         <li>a constant index that is untyped is given type <code>int</code></li>
3714         <li>the index <code>x</code> is <i>in range</i> if <code>0 &lt;= x &lt; len(a)</code>,
3715             otherwise it is <i>out of range</i></li>
3716 </ul>
3717
3718 <p>
3719 For <code>a</code> of <a href="#Array_types">array type</a> <code>A</code>:
3720 </p>
3721 <ul>
3722         <li>a <a href="#Constants">constant</a> index must be in range</li>
3723         <li>if <code>x</code> is out of range at run time,
3724             a <a href="#Run_time_panics">run-time panic</a> occurs</li>
3725         <li><code>a[x]</code> is the array element at index <code>x</code> and the type of
3726             <code>a[x]</code> is the element type of <code>A</code></li>
3727 </ul>
3728
3729 <p>
3730 For <code>a</code> of <a href="#Pointer_types">pointer</a> to array type:
3731 </p>
3732 <ul>
3733         <li><code>a[x]</code> is shorthand for <code>(*a)[x]</code></li>
3734 </ul>
3735
3736 <p>
3737 For <code>a</code> of <a href="#Slice_types">slice type</a> <code>S</code>:
3738 </p>
3739 <ul>
3740         <li>if <code>x</code> is out of range at run time,
3741             a <a href="#Run_time_panics">run-time panic</a> occurs</li>
3742         <li><code>a[x]</code> is the slice element at index <code>x</code> and the type of
3743             <code>a[x]</code> is the element type of <code>S</code></li>
3744 </ul>
3745
3746 <p>
3747 For <code>a</code> of <a href="#String_types">string type</a>:
3748 </p>
3749 <ul>
3750         <li>a <a href="#Constants">constant</a> index must be in range
3751             if the string <code>a</code> is also constant</li>
3752         <li>if <code>x</code> is out of range at run time,
3753             a <a href="#Run_time_panics">run-time panic</a> occurs</li>
3754         <li><code>a[x]</code> is the non-constant byte value at index <code>x</code> and the type of
3755             <code>a[x]</code> is <code>byte</code></li>
3756         <li><code>a[x]</code> may not be assigned to</li>
3757 </ul>
3758
3759 <p>
3760 For <code>a</code> of <a href="#Map_types">map type</a> <code>M</code>:
3761 </p>
3762 <ul>
3763         <li><code>x</code>'s type must be
3764             <a href="#Assignability">assignable</a>
3765             to the key type of <code>M</code></li>
3766         <li>if the map contains an entry with key <code>x</code>,
3767             <code>a[x]</code> is the map element with key <code>x</code>
3768             and the type of <code>a[x]</code> is the element type of <code>M</code></li>
3769         <li>if the map is <code>nil</code> or does not contain such an entry,
3770             <code>a[x]</code> is the <a href="#The_zero_value">zero value</a>
3771             for the element type of <code>M</code></li>
3772 </ul>
3773
3774 <p>
3775 For <code>a</code> of <a href="#Type_parameters">type parameter type</a> <code>P</code>:
3776 </p>
3777 <ul>
3778         <li><code>P</code> must have <a href="#Structure_of_interfaces">specific types</a>.</li>
3779         <li>The index expression <code>a[x]</code> must be valid for values
3780             of all specific types of <code>P</code>.</li>
3781         <li>The element types of all specific types of <code>P</code> must be identical.
3782             In this context, the element type of a string type is <code>byte</code>.</li>
3783         <li>If there is a map type among the specific types of <code>P</code>,
3784             all specific types must be map types, and the respective key types
3785             must be all identical.</li>
3786         <li><code>a[x]</code> is the array, slice, or string element at index <code>x</code>,
3787             or the map element with key <code>x</code> of the type argument
3788             that <code>P</code> is instantiated with, and the type of <code>a[x]</code> is
3789             the type of the (identical) element types.</li>
3790         <li><code>a[x]</code> may not be assigned to if the specific types of <code>P</code>
3791             include string types.
3792 </ul>
3793
3794 <p>
3795 Otherwise <code>a[x]</code> is illegal.
3796 </p>
3797
3798 <p>
3799 An index expression on a map <code>a</code> of type <code>map[K]V</code>
3800 used in an <a href="#Assignments">assignment</a> or initialization of the special form
3801 </p>
3802
3803 <pre>
3804 v, ok = a[x]
3805 v, ok := a[x]
3806 var v, ok = a[x]
3807 </pre>
3808
3809 <p>
3810 yields an additional untyped boolean value. The value of <code>ok</code> is
3811 <code>true</code> if the key <code>x</code> is present in the map, and
3812 <code>false</code> otherwise.
3813 </p>
3814
3815 <p>
3816 Assigning to an element of a <code>nil</code> map causes a
3817 <a href="#Run_time_panics">run-time panic</a>.
3818 </p>
3819
3820
3821 <h3 id="Slice_expressions">Slice expressions</h3>
3822
3823 <p>
3824 Slice expressions construct a substring or slice from a string, array, pointer
3825 to array, or slice. There are two variants: a simple form that specifies a low
3826 and high bound, and a full form that also specifies a bound on the capacity.
3827 </p>
3828
3829 <h4>Simple slice expressions</h4>
3830
3831 <p>
3832 For a string, array, pointer to array, or slice <code>a</code>, the primary expression
3833 </p>
3834
3835 <pre>
3836 a[low : high]
3837 </pre>
3838
3839 <p>
3840 constructs a substring or slice. The <i>indices</i> <code>low</code> and
3841 <code>high</code> select which elements of operand <code>a</code> appear
3842 in the result. The result has indices starting at 0 and length equal to
3843 <code>high</code>&nbsp;-&nbsp;<code>low</code>.
3844 After slicing the array <code>a</code>
3845 </p>
3846
3847 <pre>
3848 a := [5]int{1, 2, 3, 4, 5}
3849 s := a[1:4]
3850 </pre>
3851
3852 <p>
3853 the slice <code>s</code> has type <code>[]int</code>, length 3, capacity 4, and elements
3854 </p>
3855
3856 <pre>
3857 s[0] == 2
3858 s[1] == 3
3859 s[2] == 4
3860 </pre>
3861
3862 <p>
3863 For convenience, any of the indices may be omitted. A missing <code>low</code>
3864 index defaults to zero; a missing <code>high</code> index defaults to the length of the
3865 sliced operand:
3866 </p>
3867
3868 <pre>
3869 a[2:]  // same as a[2 : len(a)]
3870 a[:3]  // same as a[0 : 3]
3871 a[:]   // same as a[0 : len(a)]
3872 </pre>
3873
3874 <p>
3875 If <code>a</code> is a pointer to an array, <code>a[low : high]</code> is shorthand for
3876 <code>(*a)[low : high]</code>.
3877 </p>
3878
3879 <p>
3880 For arrays or strings, the indices are <i>in range</i> if
3881 <code>0</code> &lt;= <code>low</code> &lt;= <code>high</code> &lt;= <code>len(a)</code>,
3882 otherwise they are <i>out of range</i>.
3883 For slices, the upper index bound is the slice capacity <code>cap(a)</code> rather than the length.
3884 A <a href="#Constants">constant</a> index must be non-negative and
3885 <a href="#Representability">representable</a> by a value of type
3886 <code>int</code>; for arrays or constant strings, constant indices must also be in range.
3887 If both indices are constant, they must satisfy <code>low &lt;= high</code>.
3888 If the indices are out of range at run time, a <a href="#Run_time_panics">run-time panic</a> occurs.
3889 </p>
3890
3891 <p>
3892 Except for <a href="#Constants">untyped strings</a>, if the sliced operand is a string or slice,
3893 the result of the slice operation is a non-constant value of the same type as the operand.
3894 For untyped string operands the result is a non-constant value of type <code>string</code>.
3895 If the sliced operand is an array, it must be <a href="#Address_operators">addressable</a>
3896 and the result of the slice operation is a slice with the same element type as the array.
3897 </p>
3898
3899 <p>
3900 If the sliced operand of a valid slice expression is a <code>nil</code> slice, the result
3901 is a <code>nil</code> slice. Otherwise, if the result is a slice, it shares its underlying
3902 array with the operand.
3903 </p>
3904
3905 <pre>
3906 var a [10]int
3907 s1 := a[3:7]   // underlying array of s1 is array a; &amp;s1[2] == &amp;a[5]
3908 s2 := s1[1:4]  // underlying array of s2 is underlying array of s1 which is array a; &amp;s2[1] == &amp;a[5]
3909 s2[1] = 42     // s2[1] == s1[2] == a[5] == 42; they all refer to the same underlying array element
3910 </pre>
3911
3912
3913 <h4>Full slice expressions</h4>
3914
3915 <p>
3916 For an array, pointer to array, or slice <code>a</code> (but not a string), the primary expression
3917 </p>
3918
3919 <pre>
3920 a[low : high : max]
3921 </pre>
3922
3923 <p>
3924 constructs a slice of the same type, and with the same length and elements as the simple slice
3925 expression <code>a[low : high]</code>. Additionally, it controls the resulting slice's capacity
3926 by setting it to <code>max - low</code>. Only the first index may be omitted; it defaults to 0.
3927 After slicing the array <code>a</code>
3928 </p>
3929
3930 <pre>
3931 a := [5]int{1, 2, 3, 4, 5}
3932 t := a[1:3:5]
3933 </pre>
3934
3935 <p>
3936 the slice <code>t</code> has type <code>[]int</code>, length 2, capacity 4, and elements
3937 </p>
3938
3939 <pre>
3940 t[0] == 2
3941 t[1] == 3
3942 </pre>
3943
3944 <p>
3945 As for simple slice expressions, if <code>a</code> is a pointer to an array,
3946 <code>a[low : high : max]</code> is shorthand for <code>(*a)[low : high : max]</code>.
3947 If the sliced operand is an array, it must be <a href="#Address_operators">addressable</a>.
3948 </p>
3949
3950 <p>
3951 The indices are <i>in range</i> if <code>0 &lt;= low &lt;= high &lt;= max &lt;= cap(a)</code>,
3952 otherwise they are <i>out of range</i>.
3953 A <a href="#Constants">constant</a> index must be non-negative and
3954 <a href="#Representability">representable</a> by a value of type
3955 <code>int</code>; for arrays, constant indices must also be in range.
3956 If multiple indices are constant, the constants that are present must be in range relative to each
3957 other.
3958 If the indices are out of range at run time, a <a href="#Run_time_panics">run-time panic</a> occurs.
3959 </p>
3960
3961 <h3 id="Type_assertions">Type assertions</h3>
3962
3963 <p>
3964 For an expression <code>x</code> of <a href="#Interface_types">interface type</a>,
3965 but not a <a href="#Type_parameters">type parameter</a>, and a type <code>T</code>,
3966 the primary expression
3967 </p>
3968
3969 <pre>
3970 x.(T)
3971 </pre>
3972
3973 <p>
3974 asserts that <code>x</code> is not <code>nil</code>
3975 and that the value stored in <code>x</code> is of type <code>T</code>.
3976 The notation <code>x.(T)</code> is called a <i>type assertion</i>.
3977 </p>
3978 <p>
3979 More precisely, if <code>T</code> is not an interface type, <code>x.(T)</code> asserts
3980 that the dynamic type of <code>x</code> is <a href="#Type_identity">identical</a>
3981 to the type <code>T</code>.
3982 In this case, <code>T</code> must <a href="#Method_sets">implement</a> the (interface) type of <code>x</code>;
3983 otherwise the type assertion is invalid since it is not possible for <code>x</code>
3984 to store a value of type <code>T</code>.
3985 If <code>T</code> is an interface type, <code>x.(T)</code> asserts that the dynamic type
3986 of <code>x</code> implements the interface <code>T</code>.
3987 </p>
3988 <p>
3989 If the type assertion holds, the value of the expression is the value
3990 stored in <code>x</code> and its type is <code>T</code>. If the type assertion is false,
3991 a <a href="#Run_time_panics">run-time panic</a> occurs.
3992 In other words, even though the dynamic type of <code>x</code>
3993 is known only at run time, the type of <code>x.(T)</code> is
3994 known to be <code>T</code> in a correct program.
3995 </p>
3996
3997 <pre>
3998 var x interface{} = 7          // x has dynamic type int and value 7
3999 i := x.(int)                   // i has type int and value 7
4000
4001 type I interface { m() }
4002
4003 func f(y I) {
4004         s := y.(string)        // illegal: string does not implement I (missing method m)
4005         r := y.(io.Reader)     // r has type io.Reader and the dynamic type of y must implement both I and io.Reader
4006         …
4007 }
4008 </pre>
4009
4010 <p>
4011 A type assertion used in an <a href="#Assignments">assignment</a> or initialization of the special form
4012 </p>
4013
4014 <pre>
4015 v, ok = x.(T)
4016 v, ok := x.(T)
4017 var v, ok = x.(T)
4018 var v, ok interface{} = x.(T) // dynamic types of v and ok are T and bool
4019 </pre>
4020
4021 <p>
4022 yields an additional untyped boolean value. The value of <code>ok</code> is <code>true</code>
4023 if the assertion holds. Otherwise it is <code>false</code> and the value of <code>v</code> is
4024 the <a href="#The_zero_value">zero value</a> for type <code>T</code>.
4025 No <a href="#Run_time_panics">run-time panic</a> occurs in this case.
4026 </p>
4027
4028
4029 <h3 id="Calls">Calls</h3>
4030
4031 <p>
4032 Given an expression <code>f</code> of function type
4033 <code>F</code>,
4034 </p>
4035
4036 <pre>
4037 f(a1, a2, … an)
4038 </pre>
4039
4040 <p>
4041 calls <code>f</code> with arguments <code>a1, a2, … an</code>.
4042 Except for one special case, arguments must be single-valued expressions
4043 <a href="#Assignability">assignable</a> to the parameter types of
4044 <code>F</code> and are evaluated before the function is called.
4045 The type of the expression is the result type
4046 of <code>F</code>.
4047 A method invocation is similar but the method itself
4048 is specified as a selector upon a value of the receiver type for
4049 the method.
4050 </p>
4051
4052 <pre>
4053 math.Atan2(x, y)  // function call
4054 var pt *Point
4055 pt.Scale(3.5)     // method call with receiver pt
4056 </pre>
4057
4058 <p>
4059 If <code>f</code> denotes a parameterized function, it must be
4060 <a href="#Instantiations">instantiated</a> before it can be called
4061 or used as a function value.
4062 </p>
4063
4064 <p>
4065 In a function call, the function value and arguments are evaluated in
4066 <a href="#Order_of_evaluation">the usual order</a>.
4067 After they are evaluated, the parameters of the call are passed by value to the function
4068 and the called function begins execution.
4069 The return parameters of the function are passed by value
4070 back to the caller when the function returns.
4071 </p>
4072
4073 <p>
4074 Calling a <code>nil</code> function value
4075 causes a <a href="#Run_time_panics">run-time panic</a>.
4076 </p>
4077
4078 <p>
4079 As a special case, if the return values of a function or method
4080 <code>g</code> are equal in number and individually
4081 assignable to the parameters of another function or method
4082 <code>f</code>, then the call <code>f(g(<i>parameters_of_g</i>))</code>
4083 will invoke <code>f</code> after binding the return values of
4084 <code>g</code> to the parameters of <code>f</code> in order.  The call
4085 of <code>f</code> must contain no parameters other than the call of <code>g</code>,
4086 and <code>g</code> must have at least one return value.
4087 If <code>f</code> has a final <code>...</code> parameter, it is
4088 assigned the return values of <code>g</code> that remain after
4089 assignment of regular parameters.
4090 </p>
4091
4092 <pre>
4093 func Split(s string, pos int) (string, string) {
4094         return s[0:pos], s[pos:]
4095 }
4096
4097 func Join(s, t string) string {
4098         return s + t
4099 }
4100
4101 if Join(Split(value, len(value)/2)) != value {
4102         log.Panic("test fails")
4103 }
4104 </pre>
4105
4106 <p>
4107 A method call <code>x.m()</code> is valid if the <a href="#Method_sets">method set</a>
4108 of (the type of) <code>x</code> contains <code>m</code> and the
4109 argument list can be assigned to the parameter list of <code>m</code>.
4110 If <code>x</code> is <a href="#Address_operators">addressable</a> and <code>&amp;x</code>'s method
4111 set contains <code>m</code>, <code>x.m()</code> is shorthand
4112 for <code>(&amp;x).m()</code>:
4113 </p>
4114
4115 <pre>
4116 var p Point
4117 p.Scale(3.5)
4118 </pre>
4119
4120 <p>
4121 There is no distinct method type and there are no method literals.
4122 </p>
4123
4124 <h3 id="Passing_arguments_to_..._parameters">Passing arguments to <code>...</code> parameters</h3>
4125
4126 <p>
4127 If <code>f</code> is <a href="#Function_types">variadic</a> with a final
4128 parameter <code>p</code> of type <code>...T</code>, then within <code>f</code>
4129 the type of <code>p</code> is equivalent to type <code>[]T</code>.
4130 If <code>f</code> is invoked with no actual arguments for <code>p</code>,
4131 the value passed to <code>p</code> is <code>nil</code>.
4132 Otherwise, the value passed is a new slice
4133 of type <code>[]T</code> with a new underlying array whose successive elements
4134 are the actual arguments, which all must be <a href="#Assignability">assignable</a>
4135 to <code>T</code>. The length and capacity of the slice is therefore
4136 the number of arguments bound to <code>p</code> and may differ for each
4137 call site.
4138 </p>
4139
4140 <p>
4141 Given the function and calls
4142 </p>
4143 <pre>
4144 func Greeting(prefix string, who ...string)
4145 Greeting("nobody")
4146 Greeting("hello:", "Joe", "Anna", "Eileen")
4147 </pre>
4148
4149 <p>
4150 within <code>Greeting</code>, <code>who</code> will have the value
4151 <code>nil</code> in the first call, and
4152 <code>[]string{"Joe", "Anna", "Eileen"}</code> in the second.
4153 </p>
4154
4155 <p>
4156 If the final argument is assignable to a slice type <code>[]T</code> and
4157 is followed by <code>...</code>, it is passed unchanged as the value
4158 for a <code>...T</code> parameter. In this case no new slice is created.
4159 </p>
4160
4161 <p>
4162 Given the slice <code>s</code> and call
4163 </p>
4164
4165 <pre>
4166 s := []string{"James", "Jasmine"}
4167 Greeting("goodbye:", s...)
4168 </pre>
4169
4170 <p>
4171 within <code>Greeting</code>, <code>who</code> will have the same value as <code>s</code>
4172 with the same underlying array.
4173 </p>
4174
4175 <h3 id="Instantiations">Instantiations</h3>
4176
4177 <p>
4178 A parameterized function or type is <i>instantiated</i> by substituting <i>type arguments</i>
4179 for the type parameters.
4180 Instantiation proceeds in two phases:
4181 </p>
4182
4183 <ol>
4184 <li>
4185 Each type argument is substituted for its corresponding type parameter in the parameterized
4186 declaration.
4187 This substitution happens across the entire function or type declaration,
4188 including the type parameter list itself and any types in that list.
4189 </li>
4190
4191 <li>
4192 After substitution, each type argument must <a href="#Interface_types">implement</a>
4193 the <a href="#Type_parameter_lists">constraint</a> (instantiated, if necessary)
4194 of the corresponding type parameter. Otherwise instantiation fails.
4195 </li>
4196 </ol>
4197
4198 <p>
4199 Instantiating a type results in a new non-parameterized <a href="#Types">named type</a>;
4200 instantiating a function produces a new non-parameterized function.
4201 </p>
4202
4203 <pre>
4204 type parameter list    type arguments    after substitution
4205
4206 [P any]                int               [int any]
4207 [S ~[]E, E any]        []int, int        [[]int ~[]int, int any]
4208 [P io.Writer]          string            [string io.Writer]         // illegal: string doesn't implement io.Writer
4209 </pre>
4210
4211 <p>
4212 Type arguments may be provided explicitly, or they may be partially or completely
4213 <a href="#Type_inference">inferred</a>.
4214 A partially provided type argument list cannot be empty; there must be at least the
4215 first argument.
4216 </p>
4217
4218 <pre>
4219 type T[P1 ~int, P2 ~[]P1] struct{ … }
4220
4221 T[]            // illegal: at least the first type argument must be present, even if it could be inferred
4222 T[int]         // argument for P1 explicitly provided, argument for P2 inferred
4223 T[int, []int]  // both arguments explicitly provided
4224 </pre>
4225
4226 <p>
4227 A partial type argument list specifies a prefix of the full list of type arguments, leaving
4228 the remaining arguments to be inferred. Loosely speaking, type arguments may be omitted from
4229 "right to left".
4230 </p>
4231
4232 <p>
4233 Parameterized types, and parameterized functions that are not <a href="#Calls">called</a>,
4234 require a type argument list for instantiation; if the list is partial, all
4235 remaining type arguments must be inferrable.
4236 Calls to parameterized functions may provide a (possibly partial) type
4237 argument list, or may omit it entirely if the omitted type arguments are
4238 inferrable from the ordinary (non-type) function arguments.
4239 </p>
4240
4241 <pre>
4242 func min[T constraints.Ordered](x, y T) T { … }
4243
4244 f := min                   // illegal: min must be instantiated when used without being called
4245 minInt := min[int]         // minInt has type func(x, y int) int
4246 a := minInt(2, 3)          // a has value 2 of type int
4247 b := min[float64](2.0, 3)  // b has value 2.0 of type float64
4248 c := min(b, -1)            // c has value -1.0 of type float64
4249 </pre>
4250
4251 <h3 id="Type_inference">Type inference</h3>
4252
4253 <p>
4254 Missing type arguments may be <i>inferred</i> by a series of steps, described below.
4255 Each step attempts to use known information to infer additional type arguments.
4256 Type inference stops as soon as all type arguments are known.
4257 After type inference is complete, it is still necessary to substitute all type arguments
4258 for type parameters and verify that each type argument implements the relevant constraint;
4259 it is possible for an inferred type argument to fail to implement a constraint, in which
4260 case instantiation fails.
4261 </p>
4262
4263 <p>
4264 Type inference is based on
4265 </p>
4266
4267 <ul>
4268 <li>
4269         a <a href="#Type_parameter_lists">type parameter list</a>
4270 </li>
4271 <li>
4272         a substitution map <i>M</i> initialized with the known type arguments, if any
4273 </li>
4274 <li>
4275         a (possibly empty) list of ordinary function arguments (in case of a function call only)
4276 </li>
4277 </ul>
4278
4279 <p>
4280 and then proceeds with the following steps:
4281 </p>
4282
4283 <ol>
4284 <li>
4285         apply <a href="#Function_argument_type_inference"><i>function argument type inference</i></a>
4286         to all <i>typed</i> ordinary function arguments
4287 </li>
4288 <li>
4289         apply <a href="#Constraint_type_inference"><i>constraint type inference</i></a>
4290 </li>
4291 <li>
4292         apply function argument type inference to all <i>untyped</i> ordinary function arguments
4293         using the default type for each of the untyped function arguments
4294 </li>
4295 <li>
4296         apply constraint type inference
4297 </li>
4298 </ol>
4299
4300 <p>
4301 If there are no ordinary or untyped function arguments, the respective steps are skipped.
4302 Constraint type inference is skipped if the previous step didn't infer any new type arguments,
4303 but it is run at least once if there are missing type arguments.
4304 </p>
4305
4306 <p>
4307 The substitution map <i>M</i> is carried through all steps, and each step may add entries to <i>M</i>.
4308 The process stops as soon as <i>M</i> has a type argument for each type parameter or if an inference step fails.
4309 If an inference step fails, or if <i>M</i> is still missing type arguments after the last step, type inference fails.
4310 </p>
4311
4312 <h4 id="Type_unification">Type unification</h3>
4313
4314 <p>
4315 Type inference is based on <i>type unification</i>. A single unification step
4316 applies to a <a href="#Type_inference">substitution map</a> and two types, either
4317 or both of which may be or contain type parameters. The substitution map tracks
4318 the known (explicitly provided or already inferred) type arguments: the map
4319 contains an entry <code>P</code> &RightArrow; <code>A</code> for each type
4320 parameter <code>P</code> and corresponding known type argument <code>A</code>.
4321 During unification, known type arguments take the place of their corresponding type
4322 parameters when comparing types. Unification is the process of finding substitution
4323 map entries that make the two types equivalent.
4324 </p>
4325
4326 <p>
4327 For unification, two types that don't contain any type parameters from the current type
4328 parameter list are <i>equivalent</i>
4329 if they are identical, or if they are channel types that are identical ignoring channel
4330 direction, or if their underlying types are equivalent.
4331 </p>
4332
4333 <p>
4334 Unification works by comparing the structure of pairs of types: their structure
4335 disregarding type parameters must be identical, and types other than type parameters
4336 must be equivalent.
4337 A type parameter in one type may match any complete subtype in the other type;
4338 each successful match causes an entry to be added to the substitution map.
4339 If the structure differs, or types other than type parameters are not equivalent,
4340 unification fails.
4341 </p>
4342
4343 <!--
4344 TODO(gri) Somewhere we need to describe the process of adding an entry to the
4345           substitution map: if the entry is already present, the type argument
4346           values are themselves unified.
4347 -->
4348
4349 <p>
4350 For example, if <code>T1</code> and <code>T2</code> are type parameters,
4351 <code>[]map[int]bool</code> can be unified with any of the following:
4352 </p>
4353
4354 <pre>
4355 []map[int]bool   // types are identical
4356 T1               // adds T1 &RightArrow; []map[int]bool to substitution map
4357 []T1             // adds T1 &RightArrow; map[int]bool to substitution map
4358 []map[T1]T2      // adds T1 &RightArrow; int and T2 &RightArrow; bool to substitution map
4359 </pre>
4360
4361 <p>
4362 On the other hand, <code>[]map[int]bool</code> cannot be unified with any of
4363 </p>
4364
4365 <pre>
4366 int              // int is not a slice
4367 struct{}         // a struct is not a slice
4368 []struct{}       // a struct is not a map
4369 []map[T1]string  // map element types don't match
4370 </pre>
4371
4372 <p>
4373 As an exception to this general rule, because a <a href="#Type_definitions">defined type</a>
4374 <code>D</code> and a type literal <code>L</code> are never equivalent,
4375 unification compares the underlying type of <code>D</code> with <code>L</code> instead.
4376 For example, given the defined type
4377 </p>
4378
4379 <pre>
4380 type Vector []float64
4381 </pre>
4382
4383 <p>
4384 and the type literal <code>[]E</code>, unification compares <code>[]float64</code> with
4385 <code>[]E</code> and adds an entry <code>E</code> &RightArrow; <code>float64</code> to
4386 the substitution map.
4387 </p>
4388
4389 <h4 id="Function_argument_type_inference">Function argument type inference</h3>
4390
4391 <!-- In this section and the section on constraint type inference we start with examples
4392 rather than have the examples follow the rules as is customary elsewhere in spec.
4393 Hopefully this helps building an intuition and makes the rules easier to follow. -->
4394
4395 <p>
4396 Function argument type inference infers type arguments from function arguments:
4397 if a function parameter is declared with a type <code>T</code> that uses
4398 type parameters,
4399 <a href="#Type_unification">unifying</a> the type of the corresponding
4400 function argument with <code>T</code> may infer type arguments for the type
4401 parameters used by <code>T</code>.
4402 </p>
4403
4404 <p>
4405 For instance, given the type-parameterized function
4406 </p>
4407
4408 <pre>
4409 func scale[Number ~int64|~float64|~complex128](v []Number, s Number) []Number
4410 </pre>
4411
4412 <p>
4413 and the call
4414 </p>
4415
4416 <pre>
4417 var vector []float64
4418 scaledVector := scale(vector, 42)
4419 </pre>
4420
4421 <p>
4422 the type argument for <code>Number</code> can be inferred from the function argument
4423 <code>vector</code> by unifying the type of <code>vector</code> with the corresponding
4424 parameter type: <code>[]float64</code> and <code>[]Number</code>
4425 match in structure and <code>float64</code> matches with <code>Number</code>.
4426 This adds the entry <code>Number</code> &RightArrow; <code>float64</code> to the
4427 <a href="#Type_unification">substitution map</a>.
4428 Untyped arguments, such as the second function argument <code>42</code> here, are ignored
4429 in the first round of function argument type inference and only considered if there are
4430 unresolved type parameters left.
4431 </p>
4432
4433 <p>
4434 Function argument type inference can be used when the function has ordinary parameters
4435 whose types are defined using the function's type parameters. Inference happens in two
4436 separate phases; each phase operates on a specific list of (parameter, argument) pairs:
4437 </p>
4438
4439 <ol>
4440 <li>
4441         The list <i>Lt</i> contains all (parameter, argument) pairs where the parameter
4442         type uses type parameters and where the function argument is <i>typed</i>.
4443 </li>
4444 <li>
4445         The list <i>Lu</i> contains all remaining pairs where the parameter type is a single
4446         type parameter. In this list, the respective function arguments are untyped.
4447 </li>
4448 </ol>
4449
4450 <p>
4451 Any other (parameter, argument) pair is ignored.
4452 </p>
4453
4454 <p>
4455 By construction, the arguments of the pairs in <i>Lu</i> are <i>untyped</i> constants
4456 (or the untyped boolean result of a comparison). And because <a href="#Constants">default types</a>
4457 of untyped values are always predeclared non-composite types, they can never match against
4458 a composite type, so it is sufficient to only consider parameter types that are single type
4459 parameters.
4460 </p>
4461
4462 <p>
4463 Each list is processed in a separate phase:
4464 </p>
4465
4466 <ol>
4467 <li>
4468         In the first phase, the parameter and argument types of each pair in <i>Lt</i>
4469         are unified. If unification succeeds for a pair, it may yield new entries that
4470         are added to the substitution map <i>M</i>. If unification fails, type inference
4471         fails.
4472 </li>
4473 <li>
4474         The second phase considers the entries of list <i>Lu</i>. Type parameters for
4475         which the type argument has already been determined are ignored in this phase.
4476         For each remaining pair, the parameter type (which is a single type parameter) and
4477         the <a href="#Constants">default type</a> of the corresponding untyped argument is
4478         unified. If unification fails, type inference fails.
4479 </li>
4480 </ol>
4481
4482 <p>
4483 Example:
4484 </p>
4485
4486 <pre>
4487 func min[T constraints.Ordered](x, y T) T
4488
4489 var x int
4490 min(x, 2.0)    // T is int, inferred from typed argument x; 2.0 is assignable to int
4491 min(1.0, 2.0)  // T is float64, inferred from default type for 1.0 and matches default type for 2.0
4492 min(1.0, 2)    // illegal: default type float64 (for 1.0) doesn't match default type int (for 2)
4493 </pre>
4494
4495 <h4 id="Constraint_type_inference">Constraint type inference</h3>
4496
4497 <!--
4498         The next paragraph needs to be updated for the new definition of structural type:
4499         The structural type of an interface is the single underlying type of its type set,
4500         if it exists. But for constraint type inference, if the type set consists of exactly
4501         one type, we want to use that one type (which may be a defined type, different from
4502         its underlying == structural type).
4503 -->
4504
4505 <p>
4506 Constraint type inference infers type arguments from already known
4507 type arguments by considering <a href="#Structure_of_interfaces">structural type constraints</a>:
4508 if the structural type <code>T</code> of a structural constraint is parameterized,
4509 <a href="#Type_unification">unifying</a> a known type argument with <code>T</code> may
4510 infer type arguments for other type parameters used by the structural type.
4511 </p>
4512
4513 <p>
4514 For instance, consider the type parameter list with type parameters <code>List</code> and
4515 <code>Elem</code>:
4516 </p>
4517
4518 <pre>
4519 [List ~[]Elem, Elem any]
4520 </pre>
4521
4522 <p>
4523 Constraint type inference can deduce the type of <code>Elem</code> from the type argument
4524 for <code>List</code> because <code>Elem</code> is a type parameter in the structural constraint
4525 <code>~[]Elem</code> for <code>List</code>.
4526 If the type argument is <code>Bytes</code>:
4527 </p>
4528
4529 <pre>
4530 type Bytes []byte
4531 </pre>
4532
4533 <p>
4534 unifying the underlying type of <code>Bytes</code> with the structural constraint means
4535 unifying <code>[]byte</code> with <code>[]Elem</code>. That unification succeeds and yields
4536 the <a href="#Type_unification">substitution map</a> entry
4537 <code>Elem</code> &RightArrow; <code>byte</code>.
4538 Thus, in this example, constraint type inference can infer the second type argument from the
4539 first one.
4540 </p>
4541
4542 <p>
4543 Generally, constraint type inference proceeds in two phases: Starting with a given
4544 substitution map <i>M</i>
4545 </p>
4546
4547 <ol>
4548 <li>
4549 For all type parameters with a structural constraint, unify the type parameter with the structural
4550 type of its constraint. If any unification fails, constraint type inference fails.
4551 </li>
4552
4553 <li>
4554 At this point, some entries in <i>M</i> may map type parameters to other
4555 type parameters or to types containing type parameters. For each entry
4556 <code>P</code> &RightArrow; <code>A</code> in <i>M</i> where <code>A</code> is or
4557 contains type parameters <code>Q</code> for which there exist entries
4558 <code>Q</code> &RightArrow; <code>B</code> in <i>M</i>, substitute those
4559 <code>Q</code> with the respective <code>B</code> in <code>A</code>.
4560 Stop when no further substitution is possible.
4561 </li>
4562 </ol>
4563
4564 <p>
4565 The result of constraint type inference is the final substitution map <i>M</i> from type
4566 parameters <code>P</code> to type arguments <code>A</code> where no type parameter <code>P</code>
4567 appears in any of the <code>A</code>.
4568 </p>
4569
4570 <p>
4571 For instance, given the type parameter list
4572 </p>
4573
4574 <pre>
4575 [A any, B []C, C *A]
4576 </pre>
4577
4578 <p>
4579 and the single provided type argument <code>int</code> for type parameter <code>A</code>,
4580 the initial substitution map <i>M</i> contains the entry <code>A</code> &RightArrow; <code>int</code>.
4581 </p>
4582
4583 <p>
4584 In the first phase, the type parameters <code>B</code> and <code>C</code> are unified
4585 with the structural type of their respective constraints. This adds the entries
4586 <code>B</code> &RightArrow; <code>[]C</code> and <code>C</code> &RightArrow; <code>*A</code>
4587 to <i>M</i>.
4588
4589 <p>
4590 At this point there are two entries in <i>M</i> where the right-hand side
4591 is or contains type parameters for which there exists other entries in <i>M</i>:
4592 <code>[]C</code> and <code>*A</code>.
4593 In the second phase, these type parameters are replaced with their respective
4594 types. It doesn't matter in which order this happens. Starting with the state
4595 of <i>M</i> after the first phase:
4596 </p>
4597
4598 <p>
4599 <code>A</code> &RightArrow; <code>int</code>,
4600 <code>B</code> &RightArrow; <code>[]C</code>,
4601 <code>C</code> &RightArrow; <code>*A</code>
4602 </p>
4603
4604 <p>
4605 Replace <code>A</code> on the right-hand side of &RightArrow; with <code>int</code>:
4606 </p>
4607
4608 <p>
4609 <code>A</code> &RightArrow; <code>int</code>,
4610 <code>B</code> &RightArrow; <code>[]C</code>,
4611 <code>C</code> &RightArrow; <code>*int</code>
4612 </p>
4613
4614 <p>
4615 Replace <code>C</code> on the right-hand side of &RightArrow; with <code>*int</code>:
4616 </p>
4617
4618 <p>
4619 <code>A</code> &RightArrow; <code>int</code>,
4620 <code>B</code> &RightArrow; <code>[]*int</code>,
4621 <code>C</code> &RightArrow; <code>*int</code>
4622 </p>
4623
4624 <p>
4625 At this point no further substitution is possible and the map is full.
4626 Therefore, <code>M</code> represents the final map of type parameters
4627 to type arguments for the given type parameter list.
4628 </p>
4629
4630 <h3 id="Operators">Operators</h3>
4631
4632 <p>
4633 Operators combine operands into expressions.
4634 </p>
4635
4636 <pre class="ebnf">
4637 Expression = UnaryExpr | Expression binary_op Expression .
4638 UnaryExpr  = PrimaryExpr | unary_op UnaryExpr .
4639
4640 binary_op  = "||" | "&amp;&amp;" | rel_op | add_op | mul_op .
4641 rel_op     = "==" | "!=" | "&lt;" | "&lt;=" | ">" | ">=" .
4642 add_op     = "+" | "-" | "|" | "^" .
4643 mul_op     = "*" | "/" | "%" | "&lt;&lt;" | "&gt;&gt;" | "&amp;" | "&amp;^" .
4644
4645 unary_op   = "+" | "-" | "!" | "^" | "*" | "&amp;" | "&lt;-" .
4646 </pre>
4647
4648 <p>
4649 Comparisons are discussed <a href="#Comparison_operators">elsewhere</a>.
4650 For other binary operators, the operand types must be <a href="#Type_identity">identical</a>
4651 unless the operation involves shifts or untyped <a href="#Constants">constants</a>.
4652 For operations involving constants only, see the section on
4653 <a href="#Constant_expressions">constant expressions</a>.
4654 </p>
4655
4656 <p>
4657 Except for shift operations, if one operand is an untyped <a href="#Constants">constant</a>
4658 and the other operand is not, the constant is implicitly <a href="#Conversions">converted</a>
4659 to the type of the other operand.
4660 </p>
4661
4662 <p>
4663 The right operand in a shift expression must have integer type
4664 or be an untyped constant <a href="#Representability">representable</a> by a
4665 value of type <code>uint</code>.
4666 If the left operand of a non-constant shift expression is an untyped constant,
4667 it is first implicitly converted to the type it would assume if the shift expression were
4668 replaced by its left operand alone.
4669 </p>
4670
4671 <pre>
4672 var a [1024]byte
4673 var s uint = 33
4674
4675 // The results of the following examples are given for 64-bit ints.
4676 var i = 1&lt;&lt;s                   // 1 has type int
4677 var j int32 = 1&lt;&lt;s             // 1 has type int32; j == 0
4678 var k = uint64(1&lt;&lt;s)           // 1 has type uint64; k == 1&lt;&lt;33
4679 var m int = 1.0&lt;&lt;s             // 1.0 has type int; m == 1&lt;&lt;33
4680 var n = 1.0&lt;&lt;s == j            // 1.0 has type int32; n == true
4681 var o = 1&lt;&lt;s == 2&lt;&lt;s           // 1 and 2 have type int; o == false
4682 var p = 1&lt;&lt;s == 1&lt;&lt;33          // 1 has type int; p == true
4683 var u = 1.0&lt;&lt;s                 // illegal: 1.0 has type float64, cannot shift
4684 var u1 = 1.0&lt;&lt;s != 0           // illegal: 1.0 has type float64, cannot shift
4685 var u2 = 1&lt;&lt;s != 1.0           // illegal: 1 has type float64, cannot shift
4686 var v1 float32 = 1&lt;&lt;s          // illegal: 1 has type float32, cannot shift
4687 var v2 = string(1&lt;&lt;s)          // illegal: 1 is converted to a string, cannot shift
4688 var w int64 = 1.0&lt;&lt;33          // 1.0&lt;&lt;33 is a constant shift expression; w == 1&lt;&lt;33
4689 var x = a[1.0&lt;&lt;s]              // panics: 1.0 has type int, but 1&lt;&lt;33 overflows array bounds
4690 var b = make([]byte, 1.0&lt;&lt;s)   // 1.0 has type int; len(b) == 1&lt;&lt;33
4691
4692 // The results of the following examples are given for 32-bit ints,
4693 // which means the shifts will overflow.
4694 var mm int = 1.0&lt;&lt;s            // 1.0 has type int; mm == 0
4695 var oo = 1&lt;&lt;s == 2&lt;&lt;s          // 1 and 2 have type int; oo == true
4696 var pp = 1&lt;&lt;s == 1&lt;&lt;33         // illegal: 1 has type int, but 1&lt;&lt;33 overflows int
4697 var xx = a[1.0&lt;&lt;s]             // 1.0 has type int; xx == a[0]
4698 var bb = make([]byte, 1.0&lt;&lt;s)  // 1.0 has type int; len(bb) == 0
4699 </pre>
4700
4701 <h4 id="Operator_precedence">Operator precedence</h4>
4702 <p>
4703 Unary operators have the highest precedence.
4704 As the  <code>++</code> and <code>--</code> operators form
4705 statements, not expressions, they fall
4706 outside the operator hierarchy.
4707 As a consequence, statement <code>*p++</code> is the same as <code>(*p)++</code>.
4708 <p>
4709 There are five precedence levels for binary operators.
4710 Multiplication operators bind strongest, followed by addition
4711 operators, comparison operators, <code>&amp;&amp;</code> (logical AND),
4712 and finally <code>||</code> (logical OR):
4713 </p>
4714
4715 <pre class="grammar">
4716 Precedence    Operator
4717     5             *  /  %  &lt;&lt;  &gt;&gt;  &amp;  &amp;^
4718     4             +  -  |  ^
4719     3             ==  !=  &lt;  &lt;=  &gt;  &gt;=
4720     2             &amp;&amp;
4721     1             ||
4722 </pre>
4723
4724 <p>
4725 Binary operators of the same precedence associate from left to right.
4726 For instance, <code>x / y * z</code> is the same as <code>(x / y) * z</code>.
4727 </p>
4728
4729 <pre>
4730 +x
4731 23 + 3*x[i]
4732 x &lt;= f()
4733 ^a &gt;&gt; b
4734 f() || g()
4735 x == y+1 &amp;&amp; &lt;-chanInt &gt; 0
4736 </pre>
4737
4738
4739 <h3 id="Arithmetic_operators">Arithmetic operators</h3>
4740 <p>
4741 Arithmetic operators apply to numeric values and yield a result of the same
4742 type as the first operand. The four standard arithmetic operators (<code>+</code>,
4743 <code>-</code>, <code>*</code>, <code>/</code>) apply to integer,
4744 floating-point, and complex types; <code>+</code> also applies to strings.
4745 The bitwise logical and shift operators apply to integers only.
4746 </p>
4747
4748 <pre class="grammar">
4749 +    sum                    integers, floats, complex values, strings
4750 -    difference             integers, floats, complex values
4751 *    product                integers, floats, complex values
4752 /    quotient               integers, floats, complex values
4753 %    remainder              integers
4754
4755 &amp;    bitwise AND            integers
4756 |    bitwise OR             integers
4757 ^    bitwise XOR            integers
4758 &amp;^   bit clear (AND NOT)    integers
4759
4760 &lt;&lt;   left shift             integer &lt;&lt; integer &gt;= 0
4761 &gt;&gt;   right shift            integer &gt;&gt; integer &gt;= 0
4762 </pre>
4763
4764 <h4 id="Integer_operators">Integer operators</h4>
4765
4766 <p>
4767 For two integer values <code>x</code> and <code>y</code>, the integer quotient
4768 <code>q = x / y</code> and remainder <code>r = x % y</code> satisfy the following
4769 relationships:
4770 </p>
4771
4772 <pre>
4773 x = q*y + r  and  |r| &lt; |y|
4774 </pre>
4775
4776 <p>
4777 with <code>x / y</code> truncated towards zero
4778 (<a href="https://en.wikipedia.org/wiki/Modulo_operation">"truncated division"</a>).
4779 </p>
4780
4781 <pre>
4782  x     y     x / y     x % y
4783  5     3       1         2
4784 -5     3      -1        -2
4785  5    -3      -1         2
4786 -5    -3       1        -2
4787 </pre>
4788
4789 <p>
4790 The one exception to this rule is that if the dividend <code>x</code> is
4791 the most negative value for the int type of <code>x</code>, the quotient
4792 <code>q = x / -1</code> is equal to <code>x</code> (and <code>r = 0</code>)
4793 due to two's-complement <a href="#Integer_overflow">integer overflow</a>:
4794 </p>
4795
4796 <pre>
4797                          x, q
4798 int8                     -128
4799 int16                  -32768
4800 int32             -2147483648
4801 int64    -9223372036854775808
4802 </pre>
4803
4804 <p>
4805 If the divisor is a <a href="#Constants">constant</a>, it must not be zero.
4806 If the divisor is zero at run time, a <a href="#Run_time_panics">run-time panic</a> occurs.
4807 If the dividend is non-negative and the divisor is a constant power of 2,
4808 the division may be replaced by a right shift, and computing the remainder may
4809 be replaced by a bitwise AND operation:
4810 </p>
4811
4812 <pre>
4813  x     x / 4     x % 4     x &gt;&gt; 2     x &amp; 3
4814  11      2         3         2          3
4815 -11     -2        -3        -3          1
4816 </pre>
4817
4818 <p>
4819 The shift operators shift the left operand by the shift count specified by the
4820 right operand, which must be non-negative. If the shift count is negative at run time,
4821 a <a href="#Run_time_panics">run-time panic</a> occurs.
4822 The shift operators implement arithmetic shifts if the left operand is a signed
4823 integer and logical shifts if it is an unsigned integer.
4824 There is no upper limit on the shift count. Shifts behave
4825 as if the left operand is shifted <code>n</code> times by 1 for a shift
4826 count of <code>n</code>.
4827 As a result, <code>x &lt;&lt; 1</code> is the same as <code>x*2</code>
4828 and <code>x &gt;&gt; 1</code> is the same as
4829 <code>x/2</code> but truncated towards negative infinity.
4830 </p>
4831
4832 <p>
4833 For integer operands, the unary operators
4834 <code>+</code>, <code>-</code>, and <code>^</code> are defined as
4835 follows:
4836 </p>
4837
4838 <pre class="grammar">
4839 +x                          is 0 + x
4840 -x    negation              is 0 - x
4841 ^x    bitwise complement    is m ^ x  with m = "all bits set to 1" for unsigned x
4842                                       and  m = -1 for signed x
4843 </pre>
4844
4845
4846 <h4 id="Integer_overflow">Integer overflow</h4>
4847
4848 <p>
4849 For unsigned integer values, the operations <code>+</code>,
4850 <code>-</code>, <code>*</code>, and <code>&lt;&lt;</code> are
4851 computed modulo 2<sup><i>n</i></sup>, where <i>n</i> is the bit width of
4852 the <a href="#Numeric_types">unsigned integer</a>'s type.
4853 Loosely speaking, these unsigned integer operations
4854 discard high bits upon overflow, and programs may rely on "wrap around".
4855 </p>
4856
4857 <p>
4858 For signed integers, the operations <code>+</code>,
4859 <code>-</code>, <code>*</code>, <code>/</code>, and <code>&lt;&lt;</code> may legally
4860 overflow and the resulting value exists and is deterministically defined
4861 by the signed integer representation, the operation, and its operands.
4862 Overflow does not cause a <a href="#Run_time_panics">run-time panic</a>.
4863 A compiler may not optimize code under the assumption that overflow does
4864 not occur. For instance, it may not assume that <code>x &lt; x + 1</code> is always true.
4865 </p>
4866
4867
4868 <h4 id="Floating_point_operators">Floating-point operators</h4>
4869
4870 <p>
4871 For floating-point and complex numbers,
4872 <code>+x</code> is the same as <code>x</code>,
4873 while <code>-x</code> is the negation of <code>x</code>.
4874 The result of a floating-point or complex division by zero is not specified beyond the
4875 IEEE-754 standard; whether a <a href="#Run_time_panics">run-time panic</a>
4876 occurs is implementation-specific.
4877 </p>
4878
4879 <p>
4880 An implementation may combine multiple floating-point operations into a single
4881 fused operation, possibly across statements, and produce a result that differs
4882 from the value obtained by executing and rounding the instructions individually.
4883 An explicit floating-point type <a href="#Conversions">conversion</a> rounds to
4884 the precision of the target type, preventing fusion that would discard that rounding.
4885 </p>
4886
4887 <p>
4888 For instance, some architectures provide a "fused multiply and add" (FMA) instruction
4889 that computes <code>x*y + z</code> without rounding the intermediate result <code>x*y</code>.
4890 These examples show when a Go implementation can use that instruction:
4891 </p>
4892
4893 <pre>
4894 // FMA allowed for computing r, because x*y is not explicitly rounded:
4895 r  = x*y + z
4896 r  = z;   r += x*y
4897 t  = x*y; r = t + z
4898 *p = x*y; r = *p + z
4899 r  = x*y + float64(z)
4900
4901 // FMA disallowed for computing r, because it would omit rounding of x*y:
4902 r  = float64(x*y) + z
4903 r  = z; r += float64(x*y)
4904 t  = float64(x*y); r = t + z
4905 </pre>
4906
4907 <h4 id="String_concatenation">String concatenation</h4>
4908
4909 <p>
4910 Strings can be concatenated using the <code>+</code> operator
4911 or the <code>+=</code> assignment operator:
4912 </p>
4913
4914 <pre>
4915 s := "hi" + string(c)
4916 s += " and good bye"
4917 </pre>
4918
4919 <p>
4920 String addition creates a new string by concatenating the operands.
4921 </p>
4922
4923
4924 <h3 id="Comparison_operators">Comparison operators</h3>
4925
4926 <p>
4927 Comparison operators compare two operands and yield an untyped boolean value.
4928 </p>
4929
4930 <pre class="grammar">
4931 ==    equal
4932 !=    not equal
4933 &lt;     less
4934 &lt;=    less or equal
4935 &gt;     greater
4936 &gt;=    greater or equal
4937 </pre>
4938
4939 <p>
4940 In any comparison, the first operand
4941 must be <a href="#Assignability">assignable</a>
4942 to the type of the second operand, or vice versa.
4943 </p>
4944 <p>
4945 The equality operators <code>==</code> and <code>!=</code> apply
4946 to operands that are <i>comparable</i>.
4947 The ordering operators <code>&lt;</code>, <code>&lt;=</code>, <code>&gt;</code>, and <code>&gt;=</code>
4948 apply to operands that are <i>ordered</i>.
4949 These terms and the result of the comparisons are defined as follows:
4950 </p>
4951
4952 <ul>
4953         <li>
4954         Boolean values are comparable.
4955         Two boolean values are equal if they are either both
4956         <code>true</code> or both <code>false</code>.
4957         </li>
4958
4959         <li>
4960         Integer values are comparable and ordered, in the usual way.
4961         </li>
4962
4963         <li>
4964         Floating-point values are comparable and ordered,
4965         as defined by the IEEE-754 standard.
4966         </li>
4967
4968         <li>
4969         Complex values are comparable.
4970         Two complex values <code>u</code> and <code>v</code> are
4971         equal if both <code>real(u) == real(v)</code> and
4972         <code>imag(u) == imag(v)</code>.
4973         </li>
4974
4975         <li>
4976         String values are comparable and ordered, lexically byte-wise.
4977         </li>
4978
4979         <li>
4980         Pointer values are comparable.
4981         Two pointer values are equal if they point to the same variable or if both have value <code>nil</code>.
4982         Pointers to distinct <a href="#Size_and_alignment_guarantees">zero-size</a> variables may or may not be equal.
4983         </li>
4984
4985         <li>
4986         Channel values are comparable.
4987         Two channel values are equal if they were created by the same call to
4988         <a href="#Making_slices_maps_and_channels"><code>make</code></a>
4989         or if both have value <code>nil</code>.
4990         </li>
4991
4992         <li>
4993         Interface values are comparable.
4994         Two interface values are equal if they have <a href="#Type_identity">identical</a> dynamic types
4995         and equal dynamic values or if both have value <code>nil</code>.
4996         </li>
4997
4998         <li>
4999         A value <code>x</code> of non-interface type <code>X</code> and
5000         a value <code>t</code> of interface type <code>T</code> are comparable when values
5001         of type <code>X</code> are comparable and
5002         <code>X</code> implements <code>T</code>.
5003         They are equal if <code>t</code>'s dynamic type is identical to <code>X</code>
5004         and <code>t</code>'s dynamic value is equal to <code>x</code>.
5005         </li>
5006
5007         <li>
5008         Struct values are comparable if all their fields are comparable.
5009         Two struct values are equal if their corresponding
5010         non-<a href="#Blank_identifier">blank</a> fields are equal.
5011         </li>
5012
5013         <li>
5014         Array values are comparable if values of the array element type are comparable.
5015         Two array values are equal if their corresponding elements are equal.
5016         </li>
5017 </ul>
5018
5019 <p>
5020 A comparison of two interface values with identical dynamic types
5021 causes a <a href="#Run_time_panics">run-time panic</a> if values
5022 of that type are not comparable.  This behavior applies not only to direct interface
5023 value comparisons but also when comparing arrays of interface values
5024 or structs with interface-valued fields.
5025 </p>
5026
5027 <p>
5028 Slice, map, and function values are not comparable.
5029 However, as a special case, a slice, map, or function value may
5030 be compared to the predeclared identifier <code>nil</code>.
5031 Comparison of pointer, channel, and interface values to <code>nil</code>
5032 is also allowed and follows from the general rules above.
5033 </p>
5034
5035 <pre>
5036 const c = 3 &lt; 4            // c is the untyped boolean constant true
5037
5038 type MyBool bool
5039 var x, y int
5040 var (
5041         // The result of a comparison is an untyped boolean.
5042         // The usual assignment rules apply.
5043         b3        = x == y // b3 has type bool
5044         b4 bool   = x == y // b4 has type bool
5045         b5 MyBool = x == y // b5 has type MyBool
5046 )
5047 </pre>
5048
5049 <h3 id="Logical_operators">Logical operators</h3>
5050
5051 <p>
5052 Logical operators apply to <a href="#Boolean_types">boolean</a> values
5053 and yield a result of the same type as the operands.
5054 The right operand is evaluated conditionally.
5055 </p>
5056
5057 <pre class="grammar">
5058 &amp;&amp;    conditional AND    p &amp;&amp; q  is  "if p then q else false"
5059 ||    conditional OR     p || q  is  "if p then true else q"
5060 !     NOT                !p      is  "not p"
5061 </pre>
5062
5063
5064 <h3 id="Address_operators">Address operators</h3>
5065
5066 <p>
5067 For an operand <code>x</code> of type <code>T</code>, the address operation
5068 <code>&amp;x</code> generates a pointer of type <code>*T</code> to <code>x</code>.
5069 The operand must be <i>addressable</i>,
5070 that is, either a variable, pointer indirection, or slice indexing
5071 operation; or a field selector of an addressable struct operand;
5072 or an array indexing operation of an addressable array.
5073 As an exception to the addressability requirement, <code>x</code> may also be a
5074 (possibly parenthesized)
5075 <a href="#Composite_literals">composite literal</a>.
5076 If the evaluation of <code>x</code> would cause a <a href="#Run_time_panics">run-time panic</a>,
5077 then the evaluation of <code>&amp;x</code> does too.
5078 </p>
5079
5080 <p>
5081 For an operand <code>x</code> of pointer type <code>*T</code>, the pointer
5082 indirection <code>*x</code> denotes the <a href="#Variables">variable</a> of type <code>T</code> pointed
5083 to by <code>x</code>.
5084 If <code>x</code> is <code>nil</code>, an attempt to evaluate <code>*x</code>
5085 will cause a <a href="#Run_time_panics">run-time panic</a>.
5086 </p>
5087
5088 <pre>
5089 &amp;x
5090 &amp;a[f(2)]
5091 &amp;Point{2, 3}
5092 *p
5093 *pf(x)
5094
5095 var x *int = nil
5096 *x   // causes a run-time panic
5097 &amp;*x  // causes a run-time panic
5098 </pre>
5099
5100
5101 <h3 id="Receive_operator">Receive operator</h3>
5102
5103 <p>
5104 For an operand <code>ch</code> of <a href="#Channel_types">channel type</a>,
5105 the value of the receive operation <code>&lt;-ch</code> is the value received
5106 from the channel <code>ch</code>. The channel direction must permit receive operations,
5107 and the type of the receive operation is the element type of the channel.
5108 The expression blocks until a value is available.
5109 Receiving from a <code>nil</code> channel blocks forever.
5110 A receive operation on a <a href="#Close">closed</a> channel can always proceed
5111 immediately, yielding the element type's <a href="#The_zero_value">zero value</a>
5112 after any previously sent values have been received.
5113 </p>
5114
5115 <pre>
5116 v1 := &lt;-ch
5117 v2 = &lt;-ch
5118 f(&lt;-ch)
5119 &lt;-strobe  // wait until clock pulse and discard received value
5120 </pre>
5121
5122 <p>
5123 A receive expression used in an <a href="#Assignments">assignment</a> or initialization of the special form
5124 </p>
5125
5126 <pre>
5127 x, ok = &lt;-ch
5128 x, ok := &lt;-ch
5129 var x, ok = &lt;-ch
5130 var x, ok T = &lt;-ch
5131 </pre>
5132
5133 <p>
5134 yields an additional untyped boolean result reporting whether the
5135 communication succeeded. The value of <code>ok</code> is <code>true</code>
5136 if the value received was delivered by a successful send operation to the
5137 channel, or <code>false</code> if it is a zero value generated because the
5138 channel is closed and empty.
5139 </p>
5140
5141
5142 <h3 id="Conversions">Conversions</h3>
5143
5144 <p>
5145 A conversion changes the <a href="#Types">type</a> of an expression
5146 to the type specified by the conversion.
5147 A conversion may appear literally in the source, or it may be <i>implied</i>
5148 by the context in which an expression appears.
5149 </p>
5150
5151 <p>
5152 An <i>explicit</i> conversion is an expression of the form <code>T(x)</code>
5153 where <code>T</code> is a type and <code>x</code> is an expression
5154 that can be converted to type <code>T</code>.
5155 </p>
5156
5157 <pre class="ebnf">
5158 Conversion = Type "(" Expression [ "," ] ")" .
5159 </pre>
5160
5161 <p>
5162 If the type starts with the operator <code>*</code> or <code>&lt;-</code>,
5163 or if the type starts with the keyword <code>func</code>
5164 and has no result list, it must be parenthesized when
5165 necessary to avoid ambiguity:
5166 </p>
5167
5168 <pre>
5169 *Point(p)        // same as *(Point(p))
5170 (*Point)(p)      // p is converted to *Point
5171 &lt;-chan int(c)    // same as &lt;-(chan int(c))
5172 (&lt;-chan int)(c)  // c is converted to &lt;-chan int
5173 func()(x)        // function signature func() x
5174 (func())(x)      // x is converted to func()
5175 (func() int)(x)  // x is converted to func() int
5176 func() int(x)    // x is converted to func() int (unambiguous)
5177 </pre>
5178
5179 <p>
5180 A <a href="#Constants">constant</a> value <code>x</code> can be converted to
5181 type <code>T</code> if <code>x</code> is <a href="#Representability">representable</a>
5182 by a value of <code>T</code>.
5183 As a special case, an integer constant <code>x</code> can be explicitly converted to a
5184 <a href="#String_types">string type</a> using the
5185 <a href="#Conversions_to_and_from_a_string_type">same rule</a>
5186 as for non-constant <code>x</code>.
5187 </p>
5188
5189 <p>
5190 Converting a constant to a type that is not a <a href="#Type_parameters">type parameter</a>
5191 yields a typed constant.
5192 Converting a constant to a type parameter yields a non-constant value of that type.     
5193 </p>
5194
5195 <pre>
5196 uint(iota)               // iota value of type uint
5197 float32(2.718281828)     // 2.718281828 of type float32
5198 complex128(1)            // 1.0 + 0.0i of type complex128
5199 float32(0.49999999)      // 0.5 of type float32
5200 float64(-1e-1000)        // 0.0 of type float64
5201 string('x')              // "x" of type string
5202 string(0x266c)           // "♬" of type string
5203 MyString("foo" + "bar")  // "foobar" of type MyString
5204 string([]byte{'a'})      // not a constant: []byte{'a'} is not a constant
5205 (*int)(nil)              // not a constant: nil is not a constant, *int is not a boolean, numeric, or string type
5206 int(1.2)                 // illegal: 1.2 cannot be represented as an int
5207 string(65.0)             // illegal: 65.0 is not an integer constant
5208 </pre>
5209
5210 <p>
5211 A non-constant value <code>x</code> can be converted to type <code>T</code>
5212 in any of these cases:
5213 </p>
5214
5215 <ul>
5216         <li>
5217         <code>x</code> is <a href="#Assignability">assignable</a>
5218         to <code>T</code>.
5219         </li>
5220         <li>
5221         ignoring struct tags (see below),
5222         <code>x</code>'s type and <code>T</code> are not
5223         <a href="#Type_parameters">type parameters</a> but have
5224         <a href="#Type_identity">identical</a> <a href="#Types">underlying types</a>.
5225         </li>
5226         <li>
5227         ignoring struct tags (see below),
5228         <code>x</code>'s type and <code>T</code> are pointer types
5229         that are not <a href="#Types">named types</a>,
5230         and their pointer base types are not type parameters but
5231         have identical underlying types.
5232         </li>
5233         <li>
5234         <code>x</code>'s type and <code>T</code> are both integer or floating
5235         point types.
5236         </li>
5237         <li>
5238         <code>x</code>'s type and <code>T</code> are both complex types.
5239         </li>
5240         <li>
5241         <code>x</code> is an integer or a slice of bytes or runes
5242         and <code>T</code> is a string type.
5243         </li>
5244         <li>
5245         <code>x</code> is a string and <code>T</code> is a slice of bytes or runes.
5246         </li>
5247         <li>
5248         <code>x</code> is a slice, <code>T</code> is a pointer to an array,
5249         and the slice and array types have <a href="#Type_identity">identical</a> element types.
5250         </li>
5251 </ul>
5252
5253 <p>
5254 Additionally, if <code>T</code> or </code><code>x's</code> type <code>V</code> are type
5255 parameters with <a href="#Structure_of_interfaces">specific types</a>, <code>x</code>
5256 can also be converted to type <code>T</code> if one of the following conditions applies:
5257 </p>
5258
5259 <ul>
5260 <li>
5261 Both <code>V</code> and <code>T</code> are type parameters and a value of each
5262 specific type of <code>V</code> can be converted to each specific type
5263 of <code>T</code>.
5264 </li>
5265 <li>
5266 Only <code>V</code> is a type parameter and a value of each
5267 specific type of <code>V</code> can be converted to <code>T</code>.
5268 </li>
5269 <li>
5270 Only <code>T</code> is a type parameter and <code>x</code> can be converted to each
5271 specific type of <code>T</code>.
5272 </li>
5273 </ul>
5274
5275 <p>
5276 <a href="#Struct_types">Struct tags</a> are ignored when comparing struct types
5277 for identity for the purpose of conversion:
5278 </p>
5279
5280 <pre>
5281 type Person struct {
5282         Name    string
5283         Address *struct {
5284                 Street string
5285                 City   string
5286         }
5287 }
5288
5289 var data *struct {
5290         Name    string `json:"name"`
5291         Address *struct {
5292                 Street string `json:"street"`
5293                 City   string `json:"city"`
5294         } `json:"address"`
5295 }
5296
5297 var person = (*Person)(data)  // ignoring tags, the underlying types are identical
5298 </pre>
5299
5300 <p>
5301 Specific rules apply to (non-constant) conversions between numeric types or
5302 to and from a string type.
5303 These conversions may change the representation of <code>x</code>
5304 and incur a run-time cost.
5305 All other conversions only change the type but not the representation
5306 of <code>x</code>.
5307 </p>
5308
5309 <p>
5310 There is no linguistic mechanism to convert between pointers and integers.
5311 The package <a href="#Package_unsafe"><code>unsafe</code></a>
5312 implements this functionality under
5313 restricted circumstances.
5314 </p>
5315
5316 <h4>Conversions between numeric types</h4>
5317
5318 <p>
5319 For the conversion of non-constant numeric values, the following rules apply:
5320 </p>
5321
5322 <ol>
5323 <li>
5324 When converting between integer types, if the value is a signed integer, it is
5325 sign extended to implicit infinite precision; otherwise it is zero extended.
5326 It is then truncated to fit in the result type's size.
5327 For example, if <code>v := uint16(0x10F0)</code>, then <code>uint32(int8(v)) == 0xFFFFFFF0</code>.
5328 The conversion always yields a valid value; there is no indication of overflow.
5329 </li>
5330 <li>
5331 When converting a floating-point number to an integer, the fraction is discarded
5332 (truncation towards zero).
5333 </li>
5334 <li>
5335 When converting an integer or floating-point number to a floating-point type,
5336 or a complex number to another complex type, the result value is rounded
5337 to the precision specified by the destination type.
5338 For instance, the value of a variable <code>x</code> of type <code>float32</code>
5339 may be stored using additional precision beyond that of an IEEE-754 32-bit number,
5340 but float32(x) represents the result of rounding <code>x</code>'s value to
5341 32-bit precision. Similarly, <code>x + 0.1</code> may use more than 32 bits
5342 of precision, but <code>float32(x + 0.1)</code> does not.
5343 </li>
5344 </ol>
5345
5346 <p>
5347 In all non-constant conversions involving floating-point or complex values,
5348 if the result type cannot represent the value the conversion
5349 succeeds but the result value is implementation-dependent.
5350 </p>
5351
5352 <h4 id="Conversions_to_and_from_a_string_type">Conversions to and from a string type</h4>
5353
5354 <ol>
5355 <li>
5356 Converting a signed or unsigned integer value to a string type yields a
5357 string containing the UTF-8 representation of the integer. Values outside
5358 the range of valid Unicode code points are converted to <code>"\uFFFD"</code>.
5359
5360 <pre>
5361 string('a')       // "a"
5362 string(-1)        // "\ufffd" == "\xef\xbf\xbd"
5363 string(0xf8)      // "\u00f8" == "ø" == "\xc3\xb8"
5364 type MyString string
5365 MyString(0x65e5)  // "\u65e5" == "日" == "\xe6\x97\xa5"
5366 </pre>
5367 </li>
5368
5369 <li>
5370 Converting a slice of bytes to a string type yields
5371 a string whose successive bytes are the elements of the slice.
5372
5373 <pre>
5374 string([]byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'})   // "hellø"
5375 string([]byte{})                                     // ""
5376 string([]byte(nil))                                  // ""
5377
5378 type MyBytes []byte
5379 string(MyBytes{'h', 'e', 'l', 'l', '\xc3', '\xb8'})  // "hellø"
5380 </pre>
5381 </li>
5382
5383 <li>
5384 Converting a slice of runes to a string type yields
5385 a string that is the concatenation of the individual rune values
5386 converted to strings.
5387
5388 <pre>
5389 string([]rune{0x767d, 0x9d6c, 0x7fd4})   // "\u767d\u9d6c\u7fd4" == "白鵬翔"
5390 string([]rune{})                         // ""
5391 string([]rune(nil))                      // ""
5392
5393 type MyRunes []rune
5394 string(MyRunes{0x767d, 0x9d6c, 0x7fd4})  // "\u767d\u9d6c\u7fd4" == "白鵬翔"
5395 </pre>
5396 </li>
5397
5398 <li>
5399 Converting a value of a string type to a slice of bytes type
5400 yields a slice whose successive elements are the bytes of the string.
5401
5402 <pre>
5403 []byte("hellø")   // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}
5404 []byte("")        // []byte{}
5405
5406 MyBytes("hellø")  // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}
5407 </pre>
5408 </li>
5409
5410 <li>
5411 Converting a value of a string type to a slice of runes type
5412 yields a slice containing the individual Unicode code points of the string.
5413
5414 <pre>
5415 []rune(MyString("白鵬翔"))  // []rune{0x767d, 0x9d6c, 0x7fd4}
5416 []rune("")                 // []rune{}
5417
5418 MyRunes("白鵬翔")           // []rune{0x767d, 0x9d6c, 0x7fd4}
5419 </pre>
5420 </li>
5421 </ol>
5422
5423 <h4 id="Conversions_from_slice_to_array_pointer">Conversions from slice to array pointer</h4>
5424
5425 <p>
5426 Converting a slice to an array pointer yields a pointer to the underlying array of the slice.
5427 If the <a href="#Length_and_capacity">length</a> of the slice is less than the length of the array,
5428 a <a href="#Run_time_panics">run-time panic</a> occurs.
5429 </p>
5430
5431 <pre>
5432 s := make([]byte, 2, 4)
5433 s0 := (*[0]byte)(s)      // s0 != nil
5434 s1 := (*[1]byte)(s[1:])  // &amp;s1[0] == &amp;s[1]
5435 s2 := (*[2]byte)(s)      // &amp;s2[0] == &amp;s[0]
5436 s4 := (*[4]byte)(s)      // panics: len([4]byte) > len(s)
5437
5438 var t []string
5439 t0 := (*[0]string)(t)    // t0 == nil
5440 t1 := (*[1]string)(t)    // panics: len([1]string) > len(t)
5441
5442 u := make([]byte, 0)
5443 u0 := (*[0]byte)(u)      // u0 != nil
5444 </pre>
5445
5446 <h3 id="Constant_expressions">Constant expressions</h3>
5447
5448 <p>
5449 Constant expressions may contain only <a href="#Constants">constant</a>
5450 operands and are evaluated at compile time.
5451 </p>
5452
5453 <p>
5454 Untyped boolean, numeric, and string constants may be used as operands
5455 wherever it is legal to use an operand of boolean, numeric, or string type,
5456 respectively.
5457 </p>
5458
5459 <p>
5460 A constant <a href="#Comparison_operators">comparison</a> always yields
5461 an untyped boolean constant.  If the left operand of a constant
5462 <a href="#Operators">shift expression</a> is an untyped constant, the
5463 result is an integer constant; otherwise it is a constant of the same
5464 type as the left operand, which must be of
5465 <a href="#Numeric_types">integer type</a>.
5466 </p>
5467
5468 <p>
5469 Any other operation on untyped constants results in an untyped constant of the
5470 same kind; that is, a boolean, integer, floating-point, complex, or string
5471 constant.
5472 If the untyped operands of a binary operation (other than a shift) are of
5473 different kinds, the result is of the operand's kind that appears later in this
5474 list: integer, rune, floating-point, complex.
5475 For example, an untyped integer constant divided by an
5476 untyped complex constant yields an untyped complex constant.
5477 </p>
5478
5479 <pre>
5480 const a = 2 + 3.0          // a == 5.0   (untyped floating-point constant)
5481 const b = 15 / 4           // b == 3     (untyped integer constant)
5482 const c = 15 / 4.0         // c == 3.75  (untyped floating-point constant)
5483 const Θ float64 = 3/2      // Θ == 1.0   (type float64, 3/2 is integer division)
5484 const Π float64 = 3/2.     // Π == 1.5   (type float64, 3/2. is float division)
5485 const d = 1 &lt;&lt; 3.0         // d == 8     (untyped integer constant)
5486 const e = 1.0 &lt;&lt; 3         // e == 8     (untyped integer constant)
5487 const f = int32(1) &lt;&lt; 33   // illegal    (constant 8589934592 overflows int32)
5488 const g = float64(2) &gt;&gt; 1  // illegal    (float64(2) is a typed floating-point constant)
5489 const h = "foo" &gt; "bar"    // h == true  (untyped boolean constant)
5490 const j = true             // j == true  (untyped boolean constant)
5491 const k = 'w' + 1          // k == 'x'   (untyped rune constant)
5492 const l = "hi"             // l == "hi"  (untyped string constant)
5493 const m = string(k)        // m == "x"   (type string)
5494 const Σ = 1 - 0.707i       //            (untyped complex constant)
5495 const Δ = Σ + 2.0e-4       //            (untyped complex constant)
5496 const Φ = iota*1i - 1/1i   //            (untyped complex constant)
5497 </pre>
5498
5499 <p>
5500 Applying the built-in function <code>complex</code> to untyped
5501 integer, rune, or floating-point constants yields
5502 an untyped complex constant.
5503 </p>
5504
5505 <pre>
5506 const ic = complex(0, c)   // ic == 3.75i  (untyped complex constant)
5507 const iΘ = complex(0, Θ)   // iΘ == 1i     (type complex128)
5508 </pre>
5509
5510 <p>
5511 Constant expressions are always evaluated exactly; intermediate values and the
5512 constants themselves may require precision significantly larger than supported
5513 by any predeclared type in the language. The following are legal declarations:
5514 </p>
5515
5516 <pre>
5517 const Huge = 1 &lt;&lt; 100         // Huge == 1267650600228229401496703205376  (untyped integer constant)
5518 const Four int8 = Huge &gt;&gt; 98  // Four == 4                                (type int8)
5519 </pre>
5520
5521 <p>
5522 The divisor of a constant division or remainder operation must not be zero:
5523 </p>
5524
5525 <pre>
5526 3.14 / 0.0   // illegal: division by zero
5527 </pre>
5528
5529 <p>
5530 The values of <i>typed</i> constants must always be accurately
5531 <a href="#Representability">representable</a> by values
5532 of the constant type. The following constant expressions are illegal:
5533 </p>
5534
5535 <pre>
5536 uint(-1)     // -1 cannot be represented as a uint
5537 int(3.14)    // 3.14 cannot be represented as an int
5538 int64(Huge)  // 1267650600228229401496703205376 cannot be represented as an int64
5539 Four * 300   // operand 300 cannot be represented as an int8 (type of Four)
5540 Four * 100   // product 400 cannot be represented as an int8 (type of Four)
5541 </pre>
5542
5543 <p>
5544 The mask used by the unary bitwise complement operator <code>^</code> matches
5545 the rule for non-constants: the mask is all 1s for unsigned constants
5546 and -1 for signed and untyped constants.
5547 </p>
5548
5549 <pre>
5550 ^1         // untyped integer constant, equal to -2
5551 uint8(^1)  // illegal: same as uint8(-2), -2 cannot be represented as a uint8
5552 ^uint8(1)  // typed uint8 constant, same as 0xFF ^ uint8(1) = uint8(0xFE)
5553 int8(^1)   // same as int8(-2)
5554 ^int8(1)   // same as -1 ^ int8(1) = -2
5555 </pre>
5556
5557 <p>
5558 Implementation restriction: A compiler may use rounding while
5559 computing untyped floating-point or complex constant expressions; see
5560 the implementation restriction in the section
5561 on <a href="#Constants">constants</a>.  This rounding may cause a
5562 floating-point constant expression to be invalid in an integer
5563 context, even if it would be integral when calculated using infinite
5564 precision, and vice versa.
5565 </p>
5566
5567
5568 <h3 id="Order_of_evaluation">Order of evaluation</h3>
5569
5570 <p>
5571 At package level, <a href="#Package_initialization">initialization dependencies</a>
5572 determine the evaluation order of individual initialization expressions in
5573 <a href="#Variable_declarations">variable declarations</a>.
5574 Otherwise, when evaluating the <a href="#Operands">operands</a> of an
5575 expression, assignment, or
5576 <a href="#Return_statements">return statement</a>,
5577 all function calls, method calls, and
5578 communication operations are evaluated in lexical left-to-right
5579 order.
5580 </p>
5581
5582 <p>
5583 For example, in the (function-local) assignment
5584 </p>
5585 <pre>
5586 y[f()], ok = g(h(), i()+x[j()], &lt;-c), k()
5587 </pre>
5588 <p>
5589 the function calls and communication happen in the order
5590 <code>f()</code>, <code>h()</code>, <code>i()</code>, <code>j()</code>,
5591 <code>&lt;-c</code>, <code>g()</code>, and <code>k()</code>.
5592 However, the order of those events compared to the evaluation
5593 and indexing of <code>x</code> and the evaluation
5594 of <code>y</code> is not specified.
5595 </p>
5596
5597 <pre>
5598 a := 1
5599 f := func() int { a++; return a }
5600 x := []int{a, f()}            // x may be [1, 2] or [2, 2]: evaluation order between a and f() is not specified
5601 m := map[int]int{a: 1, a: 2}  // m may be {2: 1} or {2: 2}: evaluation order between the two map assignments is not specified
5602 n := map[int]int{a: f()}      // n may be {2: 3} or {3: 3}: evaluation order between the key and the value is not specified
5603 </pre>
5604
5605 <p>
5606 At package level, initialization dependencies override the left-to-right rule
5607 for individual initialization expressions, but not for operands within each
5608 expression:
5609 </p>
5610
5611 <pre>
5612 var a, b, c = f() + v(), g(), sqr(u()) + v()
5613
5614 func f() int        { return c }
5615 func g() int        { return a }
5616 func sqr(x int) int { return x*x }
5617
5618 // functions u and v are independent of all other variables and functions
5619 </pre>
5620
5621 <p>
5622 The function calls happen in the order
5623 <code>u()</code>, <code>sqr()</code>, <code>v()</code>,
5624 <code>f()</code>, <code>v()</code>, and <code>g()</code>.
5625 </p>
5626
5627 <p>
5628 Floating-point operations within a single expression are evaluated according to
5629 the associativity of the operators.  Explicit parentheses affect the evaluation
5630 by overriding the default associativity.
5631 In the expression <code>x + (y + z)</code> the addition <code>y + z</code>
5632 is performed before adding <code>x</code>.
5633 </p>
5634
5635 <h2 id="Statements">Statements</h2>
5636
5637 <p>
5638 Statements control execution.
5639 </p>
5640
5641 <pre class="ebnf">
5642 Statement =
5643         Declaration | LabeledStmt | SimpleStmt |
5644         GoStmt | ReturnStmt | BreakStmt | ContinueStmt | GotoStmt |
5645         FallthroughStmt | Block | IfStmt | SwitchStmt | SelectStmt | ForStmt |
5646         DeferStmt .
5647
5648 SimpleStmt = EmptyStmt | ExpressionStmt | SendStmt | IncDecStmt | Assignment | ShortVarDecl .
5649 </pre>
5650
5651 <h3 id="Terminating_statements">Terminating statements</h3>
5652
5653 <p>
5654 A <i>terminating statement</i> interrupts the regular flow of control in
5655 a <a href="#Blocks">block</a>. The following statements are terminating:
5656 </p>
5657
5658 <ol>
5659 <li>
5660         A <a href="#Return_statements">"return"</a> or
5661         <a href="#Goto_statements">"goto"</a> statement.
5662         <!-- ul below only for regular layout -->
5663         <ul> </ul>
5664 </li>
5665
5666 <li>
5667         A call to the built-in function
5668         <a href="#Handling_panics"><code>panic</code></a>.
5669         <!-- ul below only for regular layout -->
5670         <ul> </ul>
5671 </li>
5672
5673 <li>
5674         A <a href="#Blocks">block</a> in which the statement list ends in a terminating statement.
5675         <!-- ul below only for regular layout -->
5676         <ul> </ul>
5677 </li>
5678
5679 <li>
5680         An <a href="#If_statements">"if" statement</a> in which:
5681         <ul>
5682         <li>the "else" branch is present, and</li>
5683         <li>both branches are terminating statements.</li>
5684         </ul>
5685 </li>
5686
5687 <li>
5688         A <a href="#For_statements">"for" statement</a> in which:
5689         <ul>
5690         <li>there are no "break" statements referring to the "for" statement, and</li>
5691         <li>the loop condition is absent, and</li>
5692         <li>the "for" statement does not use a range clause.</li>
5693         </ul>
5694 </li>
5695
5696 <li>
5697         A <a href="#Switch_statements">"switch" statement</a> in which:
5698         <ul>
5699         <li>there are no "break" statements referring to the "switch" statement,</li>
5700         <li>there is a default case, and</li>
5701         <li>the statement lists in each case, including the default, end in a terminating
5702             statement, or a possibly labeled <a href="#Fallthrough_statements">"fallthrough"
5703             statement</a>.</li>
5704         </ul>
5705 </li>
5706
5707 <li>
5708         A <a href="#Select_statements">"select" statement</a> in which:
5709         <ul>
5710         <li>there are no "break" statements referring to the "select" statement, and</li>
5711         <li>the statement lists in each case, including the default if present,
5712             end in a terminating statement.</li>
5713         </ul>
5714 </li>
5715
5716 <li>
5717         A <a href="#Labeled_statements">labeled statement</a> labeling
5718         a terminating statement.
5719 </li>
5720 </ol>
5721
5722 <p>
5723 All other statements are not terminating.
5724 </p>
5725
5726 <p>
5727 A <a href="#Blocks">statement list</a> ends in a terminating statement if the list
5728 is not empty and its final non-empty statement is terminating.
5729 </p>
5730
5731
5732 <h3 id="Empty_statements">Empty statements</h3>
5733
5734 <p>
5735 The empty statement does nothing.
5736 </p>
5737
5738 <pre class="ebnf">
5739 EmptyStmt = .
5740 </pre>
5741
5742
5743 <h3 id="Labeled_statements">Labeled statements</h3>
5744
5745 <p>
5746 A labeled statement may be the target of a <code>goto</code>,
5747 <code>break</code> or <code>continue</code> statement.
5748 </p>
5749
5750 <pre class="ebnf">
5751 LabeledStmt = Label ":" Statement .
5752 Label       = identifier .
5753 </pre>
5754
5755 <pre>
5756 Error: log.Panic("error encountered")
5757 </pre>
5758
5759
5760 <h3 id="Expression_statements">Expression statements</h3>
5761
5762 <p>
5763 With the exception of specific built-in functions,
5764 function and method <a href="#Calls">calls</a> and
5765 <a href="#Receive_operator">receive operations</a>
5766 can appear in statement context. Such statements may be parenthesized.
5767 </p>
5768
5769 <pre class="ebnf">
5770 ExpressionStmt = Expression .
5771 </pre>
5772
5773 <p>
5774 The following built-in functions are not permitted in statement context:
5775 </p>
5776
5777 <pre>
5778 append cap complex imag len make new real
5779 unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
5780 </pre>
5781
5782 <pre>
5783 h(x+y)
5784 f.Close()
5785 &lt;-ch
5786 (&lt;-ch)
5787 len("foo")  // illegal if len is the built-in function
5788 </pre>
5789
5790
5791 <h3 id="Send_statements">Send statements</h3>
5792
5793 <p>
5794 A send statement sends a value on a channel.
5795 The channel expression must be of <a href="#Channel_types">channel type</a>,
5796 the channel direction must permit send operations,
5797 and the type of the value to be sent must be <a href="#Assignability">assignable</a>
5798 to the channel's element type.
5799 </p>
5800
5801 <pre class="ebnf">
5802 SendStmt = Channel "&lt;-" Expression .
5803 Channel  = Expression .
5804 </pre>
5805
5806 <p>
5807 Both the channel and the value expression are evaluated before communication
5808 begins. Communication blocks until the send can proceed.
5809 A send on an unbuffered channel can proceed if a receiver is ready.
5810 A send on a buffered channel can proceed if there is room in the buffer.
5811 A send on a closed channel proceeds by causing a <a href="#Run_time_panics">run-time panic</a>.
5812 A send on a <code>nil</code> channel blocks forever.
5813 </p>
5814
5815 <pre>
5816 ch &lt;- 3  // send value 3 to channel ch
5817 </pre>
5818
5819
5820 <h3 id="IncDec_statements">IncDec statements</h3>
5821
5822 <p>
5823 The "++" and "--" statements increment or decrement their operands
5824 by the untyped <a href="#Constants">constant</a> <code>1</code>.
5825 As with an assignment, the operand must be <a href="#Address_operators">addressable</a>
5826 or a map index expression.
5827 </p>
5828
5829 <pre class="ebnf">
5830 IncDecStmt = Expression ( "++" | "--" ) .
5831 </pre>
5832
5833 <p>
5834 The following <a href="#Assignments">assignment statements</a> are semantically
5835 equivalent:
5836 </p>
5837
5838 <pre class="grammar">
5839 IncDec statement    Assignment
5840 x++                 x += 1
5841 x--                 x -= 1
5842 </pre>
5843
5844
5845 <h3 id="Assignments">Assignments</h3>
5846
5847 <pre class="ebnf">
5848 Assignment = ExpressionList assign_op ExpressionList .
5849
5850 assign_op = [ add_op | mul_op ] "=" .
5851 </pre>
5852
5853 <p>
5854 Each left-hand side operand must be <a href="#Address_operators">addressable</a>,
5855 a map index expression, or (for <code>=</code> assignments only) the
5856 <a href="#Blank_identifier">blank identifier</a>.
5857 Operands may be parenthesized.
5858 </p>
5859
5860 <pre>
5861 x = 1
5862 *p = f()
5863 a[i] = 23
5864 (k) = &lt;-ch  // same as: k = &lt;-ch
5865 </pre>
5866
5867 <p>
5868 An <i>assignment operation</i> <code>x</code> <i>op</i><code>=</code>
5869 <code>y</code> where <i>op</i> is a binary <a href="#Arithmetic_operators">arithmetic operator</a>
5870 is equivalent to <code>x</code> <code>=</code> <code>x</code> <i>op</i>
5871 <code>(y)</code> but evaluates <code>x</code>
5872 only once.  The <i>op</i><code>=</code> construct is a single token.
5873 In assignment operations, both the left- and right-hand expression lists
5874 must contain exactly one single-valued expression, and the left-hand
5875 expression must not be the blank identifier.
5876 </p>
5877
5878 <pre>
5879 a[i] &lt;&lt;= 2
5880 i &amp;^= 1&lt;&lt;n
5881 </pre>
5882
5883 <p>
5884 A tuple assignment assigns the individual elements of a multi-valued
5885 operation to a list of variables.  There are two forms.  In the
5886 first, the right hand operand is a single multi-valued expression
5887 such as a function call, a <a href="#Channel_types">channel</a> or
5888 <a href="#Map_types">map</a> operation, or a <a href="#Type_assertions">type assertion</a>.
5889 The number of operands on the left
5890 hand side must match the number of values.  For instance, if
5891 <code>f</code> is a function returning two values,
5892 </p>
5893
5894 <pre>
5895 x, y = f()
5896 </pre>
5897
5898 <p>
5899 assigns the first value to <code>x</code> and the second to <code>y</code>.
5900 In the second form, the number of operands on the left must equal the number
5901 of expressions on the right, each of which must be single-valued, and the
5902 <i>n</i>th expression on the right is assigned to the <i>n</i>th
5903 operand on the left:
5904 </p>
5905
5906 <pre>
5907 one, two, three = '一', '二', '三'
5908 </pre>
5909
5910 <p>
5911 The <a href="#Blank_identifier">blank identifier</a> provides a way to
5912 ignore right-hand side values in an assignment:
5913 </p>
5914
5915 <pre>
5916 _ = x       // evaluate x but ignore it
5917 x, _ = f()  // evaluate f() but ignore second result value
5918 </pre>
5919
5920 <p>
5921 The assignment proceeds in two phases.
5922 First, the operands of <a href="#Index_expressions">index expressions</a>
5923 and <a href="#Address_operators">pointer indirections</a>
5924 (including implicit pointer indirections in <a href="#Selectors">selectors</a>)
5925 on the left and the expressions on the right are all
5926 <a href="#Order_of_evaluation">evaluated in the usual order</a>.
5927 Second, the assignments are carried out in left-to-right order.
5928 </p>
5929
5930 <pre>
5931 a, b = b, a  // exchange a and b
5932
5933 x := []int{1, 2, 3}
5934 i := 0
5935 i, x[i] = 1, 2  // set i = 1, x[0] = 2
5936
5937 i = 0
5938 x[i], i = 2, 1  // set x[0] = 2, i = 1
5939
5940 x[0], x[0] = 1, 2  // set x[0] = 1, then x[0] = 2 (so x[0] == 2 at end)
5941
5942 x[1], x[3] = 4, 5  // set x[1] = 4, then panic setting x[3] = 5.
5943
5944 type Point struct { x, y int }
5945 var p *Point
5946 x[2], p.x = 6, 7  // set x[2] = 6, then panic setting p.x = 7
5947
5948 i = 2
5949 x = []int{3, 5, 7}
5950 for i, x[i] = range x {  // set i, x[2] = 0, x[0]
5951         break
5952 }
5953 // after this loop, i == 0 and x == []int{3, 5, 3}
5954 </pre>
5955
5956 <p>
5957 In assignments, each value must be <a href="#Assignability">assignable</a>
5958 to the type of the operand to which it is assigned, with the following special cases:
5959 </p>
5960
5961 <ol>
5962 <li>
5963         Any typed value may be assigned to the blank identifier.
5964 </li>
5965
5966 <li>
5967         If an untyped constant
5968         is assigned to a variable of interface type or the blank identifier,
5969         the constant is first implicitly <a href="#Conversions">converted</a> to its
5970          <a href="#Constants">default type</a>.
5971 </li>
5972
5973 <li>
5974         If an untyped boolean value is assigned to a variable of interface type or
5975         the blank identifier, it is first implicitly converted to type <code>bool</code>.
5976 </li>
5977 </ol>
5978
5979 <h3 id="If_statements">If statements</h3>
5980
5981 <p>
5982 "If" statements specify the conditional execution of two branches
5983 according to the value of a boolean expression.  If the expression
5984 evaluates to true, the "if" branch is executed, otherwise, if
5985 present, the "else" branch is executed.
5986 </p>
5987
5988 <pre class="ebnf">
5989 IfStmt = "if" [ SimpleStmt ";" ] Expression Block [ "else" ( IfStmt | Block ) ] .
5990 </pre>
5991
5992 <pre>
5993 if x &gt; max {
5994         x = max
5995 }
5996 </pre>
5997
5998 <p>
5999 The expression may be preceded by a simple statement, which
6000 executes before the expression is evaluated.
6001 </p>
6002
6003 <pre>
6004 if x := f(); x &lt; y {
6005         return x
6006 } else if x &gt; z {
6007         return z
6008 } else {
6009         return y
6010 }
6011 </pre>
6012
6013
6014 <h3 id="Switch_statements">Switch statements</h3>
6015
6016 <p>
6017 "Switch" statements provide multi-way execution.
6018 An expression or type is compared to the "cases"
6019 inside the "switch" to determine which branch
6020 to execute.
6021 </p>
6022
6023 <pre class="ebnf">
6024 SwitchStmt = ExprSwitchStmt | TypeSwitchStmt .
6025 </pre>
6026
6027 <p>
6028 There are two forms: expression switches and type switches.
6029 In an expression switch, the cases contain expressions that are compared
6030 against the value of the switch expression.
6031 In a type switch, the cases contain types that are compared against the
6032 type of a specially annotated switch expression.
6033 The switch expression is evaluated exactly once in a switch statement.
6034 </p>
6035
6036 <h4 id="Expression_switches">Expression switches</h4>
6037
6038 <p>
6039 In an expression switch,
6040 the switch expression is evaluated and
6041 the case expressions, which need not be constants,
6042 are evaluated left-to-right and top-to-bottom; the first one that equals the
6043 switch expression
6044 triggers execution of the statements of the associated case;
6045 the other cases are skipped.
6046 If no case matches and there is a "default" case,
6047 its statements are executed.
6048 There can be at most one default case and it may appear anywhere in the
6049 "switch" statement.
6050 A missing switch expression is equivalent to the boolean value
6051 <code>true</code>.
6052 </p>
6053
6054 <pre class="ebnf">
6055 ExprSwitchStmt = "switch" [ SimpleStmt ";" ] [ Expression ] "{" { ExprCaseClause } "}" .
6056 ExprCaseClause = ExprSwitchCase ":" StatementList .
6057 ExprSwitchCase = "case" ExpressionList | "default" .
6058 </pre>
6059
6060 <p>
6061 If the switch expression evaluates to an untyped constant, it is first implicitly
6062 <a href="#Conversions">converted</a> to its <a href="#Constants">default type</a>.
6063 The predeclared untyped value <code>nil</code> cannot be used as a switch expression.
6064 The switch expression type must be <a href="#Comparison_operators">comparable</a>.
6065 </p>
6066
6067 <p>
6068 If a case expression is untyped, it is first implicitly <a href="#Conversions">converted</a>
6069 to the type of the switch expression.
6070 For each (possibly converted) case expression <code>x</code> and the value <code>t</code>
6071 of the switch expression, <code>x == t</code> must be a valid <a href="#Comparison_operators">comparison</a>.
6072 </p>
6073
6074 <p>
6075 In other words, the switch expression is treated as if it were used to declare and
6076 initialize a temporary variable <code>t</code> without explicit type; it is that
6077 value of <code>t</code> against which each case expression <code>x</code> is tested
6078 for equality.
6079 </p>
6080
6081 <p>
6082 In a case or default clause, the last non-empty statement
6083 may be a (possibly <a href="#Labeled_statements">labeled</a>)
6084 <a href="#Fallthrough_statements">"fallthrough" statement</a> to
6085 indicate that control should flow from the end of this clause to
6086 the first statement of the next clause.
6087 Otherwise control flows to the end of the "switch" statement.
6088 A "fallthrough" statement may appear as the last statement of all
6089 but the last clause of an expression switch.
6090 </p>
6091
6092 <p>
6093 The switch expression may be preceded by a simple statement, which
6094 executes before the expression is evaluated.
6095 </p>
6096
6097 <pre>
6098 switch tag {
6099 default: s3()
6100 case 0, 1, 2, 3: s1()
6101 case 4, 5, 6, 7: s2()
6102 }
6103
6104 switch x := f(); {  // missing switch expression means "true"
6105 case x &lt; 0: return -x
6106 default: return x
6107 }
6108
6109 switch {
6110 case x &lt; y: f1()
6111 case x &lt; z: f2()
6112 case x == 4: f3()
6113 }
6114 </pre>
6115
6116 <p>
6117 Implementation restriction: A compiler may disallow multiple case
6118 expressions evaluating to the same constant.
6119 For instance, the current compilers disallow duplicate integer,
6120 floating point, or string constants in case expressions.
6121 </p>
6122
6123 <h4 id="Type_switches">Type switches</h4>
6124
6125 <p>
6126 A type switch compares types rather than values. It is otherwise similar
6127 to an expression switch. It is marked by a special switch expression that
6128 has the form of a <a href="#Type_assertions">type assertion</a>
6129 using the keyword <code>type</code> rather than an actual type:
6130 </p>
6131
6132 <pre>
6133 switch x.(type) {
6134 // cases
6135 }
6136 </pre>
6137
6138 <p>
6139 Cases then match actual types <code>T</code> against the dynamic type of the
6140 expression <code>x</code>. As with type assertions, <code>x</code> must be of
6141 <a href="#Interface_types">interface type</a>, but not a
6142 <a href="#Type_parameters">type parameter</a>, and each non-interface type
6143 <code>T</code> listed in a case must implement the type of <code>x</code>.
6144 The types listed in the cases of a type switch must all be
6145 <a href="#Type_identity">different</a>.
6146 </p>
6147
6148 <pre class="ebnf">
6149 TypeSwitchStmt  = "switch" [ SimpleStmt ";" ] TypeSwitchGuard "{" { TypeCaseClause } "}" .
6150 TypeSwitchGuard = [ identifier ":=" ] PrimaryExpr "." "(" "type" ")" .
6151 TypeCaseClause  = TypeSwitchCase ":" StatementList .
6152 TypeSwitchCase  = "case" TypeList | "default" .
6153 </pre>
6154
6155 <p>
6156 The TypeSwitchGuard may include a
6157 <a href="#Short_variable_declarations">short variable declaration</a>.
6158 When that form is used, the variable is declared at the end of the
6159 TypeSwitchCase in the <a href="#Blocks">implicit block</a> of each clause.
6160 In clauses with a case listing exactly one type, the variable
6161 has that type; otherwise, the variable has the type of the expression
6162 in the TypeSwitchGuard.
6163 </p>
6164
6165 <p>
6166 Instead of a type, a case may use the predeclared identifier
6167 <a href="#Predeclared_identifiers"><code>nil</code></a>;
6168 that case is selected when the expression in the TypeSwitchGuard
6169 is a <code>nil</code> interface value.
6170 There may be at most one <code>nil</code> case.
6171 </p>
6172
6173 <p>
6174 Given an expression <code>x</code> of type <code>interface{}</code>,
6175 the following type switch:
6176 </p>
6177
6178 <pre>
6179 switch i := x.(type) {
6180 case nil:
6181         printString("x is nil")                // type of i is type of x (interface{})
6182 case int:
6183         printInt(i)                            // type of i is int
6184 case float64:
6185         printFloat64(i)                        // type of i is float64
6186 case func(int) float64:
6187         printFunction(i)                       // type of i is func(int) float64
6188 case bool, string:
6189         printString("type is bool or string")  // type of i is type of x (interface{})
6190 default:
6191         printString("don't know the type")     // type of i is type of x (interface{})
6192 }
6193 </pre>
6194
6195 <p>
6196 could be rewritten:
6197 </p>
6198
6199 <pre>
6200 v := x  // x is evaluated exactly once
6201 if v == nil {
6202         i := v                                 // type of i is type of x (interface{})
6203         printString("x is nil")
6204 } else if i, isInt := v.(int); isInt {
6205         printInt(i)                            // type of i is int
6206 } else if i, isFloat64 := v.(float64); isFloat64 {
6207         printFloat64(i)                        // type of i is float64
6208 } else if i, isFunc := v.(func(int) float64); isFunc {
6209         printFunction(i)                       // type of i is func(int) float64
6210 } else {
6211         _, isBool := v.(bool)
6212         _, isString := v.(string)
6213         if isBool || isString {
6214                 i := v                         // type of i is type of x (interface{})
6215                 printString("type is bool or string")
6216         } else {
6217                 i := v                         // type of i is type of x (interface{})
6218                 printString("don't know the type")
6219         }
6220 }
6221 </pre>
6222
6223 <p>
6224 The type switch guard may be preceded by a simple statement, which
6225 executes before the guard is evaluated.
6226 </p>
6227
6228 <p>
6229 The "fallthrough" statement is not permitted in a type switch.
6230 </p>
6231
6232 <h3 id="For_statements">For statements</h3>
6233
6234 <p>
6235 A "for" statement specifies repeated execution of a block. There are three forms:
6236 The iteration may be controlled by a single condition, a "for" clause, or a "range" clause.
6237 </p>
6238
6239 <pre class="ebnf">
6240 ForStmt = "for" [ Condition | ForClause | RangeClause ] Block .
6241 Condition = Expression .
6242 </pre>
6243
6244 <h4 id="For_condition">For statements with single condition</h4>
6245
6246 <p>
6247 In its simplest form, a "for" statement specifies the repeated execution of
6248 a block as long as a boolean condition evaluates to true.
6249 The condition is evaluated before each iteration.
6250 If the condition is absent, it is equivalent to the boolean value
6251 <code>true</code>.
6252 </p>
6253
6254 <pre>
6255 for a &lt; b {
6256         a *= 2
6257 }
6258 </pre>
6259
6260 <h4 id="For_clause">For statements with <code>for</code> clause</h4>
6261
6262 <p>
6263 A "for" statement with a ForClause is also controlled by its condition, but
6264 additionally it may specify an <i>init</i>
6265 and a <i>post</i> statement, such as an assignment,
6266 an increment or decrement statement. The init statement may be a
6267 <a href="#Short_variable_declarations">short variable declaration</a>, but the post statement must not.
6268 Variables declared by the init statement are re-used in each iteration.
6269 </p>
6270
6271 <pre class="ebnf">
6272 ForClause = [ InitStmt ] ";" [ Condition ] ";" [ PostStmt ] .
6273 InitStmt = SimpleStmt .
6274 PostStmt = SimpleStmt .
6275 </pre>
6276
6277 <pre>
6278 for i := 0; i &lt; 10; i++ {
6279         f(i)
6280 }
6281 </pre>
6282
6283 <p>
6284 If non-empty, the init statement is executed once before evaluating the
6285 condition for the first iteration;
6286 the post statement is executed after each execution of the block (and
6287 only if the block was executed).
6288 Any element of the ForClause may be empty but the
6289 <a href="#Semicolons">semicolons</a> are
6290 required unless there is only a condition.
6291 If the condition is absent, it is equivalent to the boolean value
6292 <code>true</code>.
6293 </p>
6294
6295 <pre>
6296 for cond { S() }    is the same as    for ; cond ; { S() }
6297 for      { S() }    is the same as    for true     { S() }
6298 </pre>
6299
6300 <h4 id="For_range">For statements with <code>range</code> clause</h4>
6301
6302 <p>
6303 A "for" statement with a "range" clause
6304 iterates through all entries of an array, slice, string or map,
6305 or values received on a channel. For each entry it assigns <i>iteration values</i>
6306 to corresponding <i>iteration variables</i> if present and then executes the block.
6307 </p>
6308
6309 <pre class="ebnf">
6310 RangeClause = [ ExpressionList "=" | IdentifierList ":=" ] "range" Expression .
6311 </pre>
6312
6313 <p>
6314 The expression on the right in the "range" clause is called the <i>range expression</i>,
6315 which may be an array, pointer to an array, slice, string, map, or channel permitting
6316 <a href="#Receive_operator">receive operations</a>.
6317 As with an assignment, if present the operands on the left must be
6318 <a href="#Address_operators">addressable</a> or map index expressions; they
6319 denote the iteration variables. If the range expression is a channel, at most
6320 one iteration variable is permitted, otherwise there may be up to two.
6321 If the last iteration variable is the <a href="#Blank_identifier">blank identifier</a>,
6322 the range clause is equivalent to the same clause without that identifier.
6323 </p>
6324
6325 <p>
6326 The range expression <code>x</code> is evaluated once before beginning the loop,
6327 with one exception: if at most one iteration variable is present and
6328 <code>len(x)</code> is <a href="#Length_and_capacity">constant</a>,
6329 the range expression is not evaluated.
6330 </p>
6331
6332 <p>
6333 Function calls on the left are evaluated once per iteration.
6334 For each iteration, iteration values are produced as follows
6335 if the respective iteration variables are present:
6336 </p>
6337
6338 <pre class="grammar">
6339 Range expression                          1st value          2nd value
6340
6341 array or slice  a  [n]E, *[n]E, or []E    index    i  int    a[i]       E
6342 string          s  string type            index    i  int    see below  rune
6343 map             m  map[K]V                key      k  K      m[k]       V
6344 channel         c  chan E, &lt;-chan E       element  e  E
6345 </pre>
6346
6347 <ol>
6348 <li>
6349 For an array, pointer to array, or slice value <code>a</code>, the index iteration
6350 values are produced in increasing order, starting at element index 0.
6351 If at most one iteration variable is present, the range loop produces
6352 iteration values from 0 up to <code>len(a)-1</code> and does not index into the array
6353 or slice itself. For a <code>nil</code> slice, the number of iterations is 0.
6354 </li>
6355
6356 <li>
6357 For a string value, the "range" clause iterates over the Unicode code points
6358 in the string starting at byte index 0.  On successive iterations, the index value will be the
6359 index of the first byte of successive UTF-8-encoded code points in the string,
6360 and the second value, of type <code>rune</code>, will be the value of
6361 the corresponding code point. If the iteration encounters an invalid
6362 UTF-8 sequence, the second value will be <code>0xFFFD</code>,
6363 the Unicode replacement character, and the next iteration will advance
6364 a single byte in the string.
6365 </li>
6366
6367 <li>
6368 The iteration order over maps is not specified
6369 and is not guaranteed to be the same from one iteration to the next.
6370 If a map entry that has not yet been reached is removed during iteration,
6371 the corresponding iteration value will not be produced. If a map entry is
6372 created during iteration, that entry may be produced during the iteration or
6373 may be skipped. The choice may vary for each entry created and from one
6374 iteration to the next.
6375 If the map is <code>nil</code>, the number of iterations is 0.
6376 </li>
6377
6378 <li>
6379 For channels, the iteration values produced are the successive values sent on
6380 the channel until the channel is <a href="#Close">closed</a>. If the channel
6381 is <code>nil</code>, the range expression blocks forever.
6382 </li>
6383 </ol>
6384
6385 <p>
6386 The iteration values are assigned to the respective
6387 iteration variables as in an <a href="#Assignments">assignment statement</a>.
6388 </p>
6389
6390 <p>
6391 The iteration variables may be declared by the "range" clause using a form of
6392 <a href="#Short_variable_declarations">short variable declaration</a>
6393 (<code>:=</code>).
6394 In this case their types are set to the types of the respective iteration values
6395 and their <a href="#Declarations_and_scope">scope</a> is the block of the "for"
6396 statement; they are re-used in each iteration.
6397 If the iteration variables are declared outside the "for" statement,
6398 after execution their values will be those of the last iteration.
6399 </p>
6400
6401 <pre>
6402 var testdata *struct {
6403         a *[7]int
6404 }
6405 for i, _ := range testdata.a {
6406         // testdata.a is never evaluated; len(testdata.a) is constant
6407         // i ranges from 0 to 6
6408         f(i)
6409 }
6410
6411 var a [10]string
6412 for i, s := range a {
6413         // type of i is int
6414         // type of s is string
6415         // s == a[i]
6416         g(i, s)
6417 }
6418
6419 var key string
6420 var val interface{}  // element type of m is assignable to val
6421 m := map[string]int{"mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6}
6422 for key, val = range m {
6423         h(key, val)
6424 }
6425 // key == last map key encountered in iteration
6426 // val == map[key]
6427
6428 var ch chan Work = producer()
6429 for w := range ch {
6430         doWork(w)
6431 }
6432
6433 // empty a channel
6434 for range ch {}
6435 </pre>
6436
6437
6438 <h3 id="Go_statements">Go statements</h3>
6439
6440 <p>
6441 A "go" statement starts the execution of a function call
6442 as an independent concurrent thread of control, or <i>goroutine</i>,
6443 within the same address space.
6444 </p>
6445
6446 <pre class="ebnf">
6447 GoStmt = "go" Expression .
6448 </pre>
6449
6450 <p>
6451 The expression must be a function or method call; it cannot be parenthesized.
6452 Calls of built-in functions are restricted as for
6453 <a href="#Expression_statements">expression statements</a>.
6454 </p>
6455
6456 <p>
6457 The function value and parameters are
6458 <a href="#Calls">evaluated as usual</a>
6459 in the calling goroutine, but
6460 unlike with a regular call, program execution does not wait
6461 for the invoked function to complete.
6462 Instead, the function begins executing independently
6463 in a new goroutine.
6464 When the function terminates, its goroutine also terminates.
6465 If the function has any return values, they are discarded when the
6466 function completes.
6467 </p>
6468
6469 <pre>
6470 go Server()
6471 go func(ch chan&lt;- bool) { for { sleep(10); ch &lt;- true }} (c)
6472 </pre>
6473
6474
6475 <h3 id="Select_statements">Select statements</h3>
6476
6477 <p>
6478 A "select" statement chooses which of a set of possible
6479 <a href="#Send_statements">send</a> or
6480 <a href="#Receive_operator">receive</a>
6481 operations will proceed.
6482 It looks similar to a
6483 <a href="#Switch_statements">"switch"</a> statement but with the
6484 cases all referring to communication operations.
6485 </p>
6486
6487 <pre class="ebnf">
6488 SelectStmt = "select" "{" { CommClause } "}" .
6489 CommClause = CommCase ":" StatementList .
6490 CommCase   = "case" ( SendStmt | RecvStmt ) | "default" .
6491 RecvStmt   = [ ExpressionList "=" | IdentifierList ":=" ] RecvExpr .
6492 RecvExpr   = Expression .
6493 </pre>
6494
6495 <p>
6496 A case with a RecvStmt may assign the result of a RecvExpr to one or
6497 two variables, which may be declared using a
6498 <a href="#Short_variable_declarations">short variable declaration</a>.
6499 The RecvExpr must be a (possibly parenthesized) receive operation.
6500 There can be at most one default case and it may appear anywhere
6501 in the list of cases.
6502 </p>
6503
6504 <p>
6505 Execution of a "select" statement proceeds in several steps:
6506 </p>
6507
6508 <ol>
6509 <li>
6510 For all the cases in the statement, the channel operands of receive operations
6511 and the channel and right-hand-side expressions of send statements are
6512 evaluated exactly once, in source order, upon entering the "select" statement.
6513 The result is a set of channels to receive from or send to,
6514 and the corresponding values to send.
6515 Any side effects in that evaluation will occur irrespective of which (if any)
6516 communication operation is selected to proceed.
6517 Expressions on the left-hand side of a RecvStmt with a short variable declaration
6518 or assignment are not yet evaluated.
6519 </li>
6520
6521 <li>
6522 If one or more of the communications can proceed,
6523 a single one that can proceed is chosen via a uniform pseudo-random selection.
6524 Otherwise, if there is a default case, that case is chosen.
6525 If there is no default case, the "select" statement blocks until
6526 at least one of the communications can proceed.
6527 </li>
6528
6529 <li>
6530 Unless the selected case is the default case, the respective communication
6531 operation is executed.
6532 </li>
6533
6534 <li>
6535 If the selected case is a RecvStmt with a short variable declaration or
6536 an assignment, the left-hand side expressions are evaluated and the
6537 received value (or values) are assigned.
6538 </li>
6539
6540 <li>
6541 The statement list of the selected case is executed.
6542 </li>
6543 </ol>
6544
6545 <p>
6546 Since communication on <code>nil</code> channels can never proceed,
6547 a select with only <code>nil</code> channels and no default case blocks forever.
6548 </p>
6549
6550 <pre>
6551 var a []int
6552 var c, c1, c2, c3, c4 chan int
6553 var i1, i2 int
6554 select {
6555 case i1 = &lt;-c1:
6556         print("received ", i1, " from c1\n")
6557 case c2 &lt;- i2:
6558         print("sent ", i2, " to c2\n")
6559 case i3, ok := (&lt;-c3):  // same as: i3, ok := &lt;-c3
6560         if ok {
6561                 print("received ", i3, " from c3\n")
6562         } else {
6563                 print("c3 is closed\n")
6564         }
6565 case a[f()] = &lt;-c4:
6566         // same as:
6567         // case t := &lt;-c4
6568         //      a[f()] = t
6569 default:
6570         print("no communication\n")
6571 }
6572
6573 for {  // send random sequence of bits to c
6574         select {
6575         case c &lt;- 0:  // note: no statement, no fallthrough, no folding of cases
6576         case c &lt;- 1:
6577         }
6578 }
6579
6580 select {}  // block forever
6581 </pre>
6582
6583
6584 <h3 id="Return_statements">Return statements</h3>
6585
6586 <p>
6587 A "return" statement in a function <code>F</code> terminates the execution
6588 of <code>F</code>, and optionally provides one or more result values.
6589 Any functions <a href="#Defer_statements">deferred</a> by <code>F</code>
6590 are executed before <code>F</code> returns to its caller.
6591 </p>
6592
6593 <pre class="ebnf">
6594 ReturnStmt = "return" [ ExpressionList ] .
6595 </pre>
6596
6597 <p>
6598 In a function without a result type, a "return" statement must not
6599 specify any result values.
6600 </p>
6601 <pre>
6602 func noResult() {
6603         return
6604 }
6605 </pre>
6606
6607 <p>
6608 There are three ways to return values from a function with a result
6609 type:
6610 </p>
6611
6612 <ol>
6613         <li>The return value or values may be explicitly listed
6614                 in the "return" statement. Each expression must be single-valued
6615                 and <a href="#Assignability">assignable</a>
6616                 to the corresponding element of the function's result type.
6617 <pre>
6618 func simpleF() int {
6619         return 2
6620 }
6621
6622 func complexF1() (re float64, im float64) {
6623         return -7.0, -4.0
6624 }
6625 </pre>
6626         </li>
6627         <li>The expression list in the "return" statement may be a single
6628                 call to a multi-valued function. The effect is as if each value
6629                 returned from that function were assigned to a temporary
6630                 variable with the type of the respective value, followed by a
6631                 "return" statement listing these variables, at which point the
6632                 rules of the previous case apply.
6633 <pre>
6634 func complexF2() (re float64, im float64) {
6635         return complexF1()
6636 }
6637 </pre>
6638         </li>
6639         <li>The expression list may be empty if the function's result
6640                 type specifies names for its <a href="#Function_types">result parameters</a>.
6641                 The result parameters act as ordinary local variables
6642                 and the function may assign values to them as necessary.
6643                 The "return" statement returns the values of these variables.
6644 <pre>
6645 func complexF3() (re float64, im float64) {
6646         re = 7.0
6647         im = 4.0
6648         return
6649 }
6650
6651 func (devnull) Write(p []byte) (n int, _ error) {
6652         n = len(p)
6653         return
6654 }
6655 </pre>
6656         </li>
6657 </ol>
6658
6659 <p>
6660 Regardless of how they are declared, all the result values are initialized to
6661 the <a href="#The_zero_value">zero values</a> for their type upon entry to the
6662 function. A "return" statement that specifies results sets the result parameters before
6663 any deferred functions are executed.
6664 </p>
6665
6666 <p>
6667 Implementation restriction: A compiler may disallow an empty expression list
6668 in a "return" statement if a different entity (constant, type, or variable)
6669 with the same name as a result parameter is in
6670 <a href="#Declarations_and_scope">scope</a> at the place of the return.
6671 </p>
6672
6673 <pre>
6674 func f(n int) (res int, err error) {
6675         if _, err := f(n-1); err != nil {
6676                 return  // invalid return statement: err is shadowed
6677         }
6678         return
6679 }
6680 </pre>
6681
6682 <h3 id="Break_statements">Break statements</h3>
6683
6684 <p>
6685 A "break" statement terminates execution of the innermost
6686 <a href="#For_statements">"for"</a>,
6687 <a href="#Switch_statements">"switch"</a>, or
6688 <a href="#Select_statements">"select"</a> statement
6689 within the same function.
6690 </p>
6691
6692 <pre class="ebnf">
6693 BreakStmt = "break" [ Label ] .
6694 </pre>
6695
6696 <p>
6697 If there is a label, it must be that of an enclosing
6698 "for", "switch", or "select" statement,
6699 and that is the one whose execution terminates.
6700 </p>
6701
6702 <pre>
6703 OuterLoop:
6704         for i = 0; i &lt; n; i++ {
6705                 for j = 0; j &lt; m; j++ {
6706                         switch a[i][j] {
6707                         case nil:
6708                                 state = Error
6709                                 break OuterLoop
6710                         case item:
6711                                 state = Found
6712                                 break OuterLoop
6713                         }
6714                 }
6715         }
6716 </pre>
6717
6718 <h3 id="Continue_statements">Continue statements</h3>
6719
6720 <p>
6721 A "continue" statement begins the next iteration of the
6722 innermost <a href="#For_statements">"for" loop</a> at its post statement.
6723 The "for" loop must be within the same function.
6724 </p>
6725
6726 <pre class="ebnf">
6727 ContinueStmt = "continue" [ Label ] .
6728 </pre>
6729
6730 <p>
6731 If there is a label, it must be that of an enclosing
6732 "for" statement, and that is the one whose execution
6733 advances.
6734 </p>
6735
6736 <pre>
6737 RowLoop:
6738         for y, row := range rows {
6739                 for x, data := range row {
6740                         if data == endOfRow {
6741                                 continue RowLoop
6742                         }
6743                         row[x] = data + bias(x, y)
6744                 }
6745         }
6746 </pre>
6747
6748 <h3 id="Goto_statements">Goto statements</h3>
6749
6750 <p>
6751 A "goto" statement transfers control to the statement with the corresponding label
6752 within the same function.
6753 </p>
6754
6755 <pre class="ebnf">
6756 GotoStmt = "goto" Label .
6757 </pre>
6758
6759 <pre>
6760 goto Error
6761 </pre>
6762
6763 <p>
6764 Executing the "goto" statement must not cause any variables to come into
6765 <a href="#Declarations_and_scope">scope</a> that were not already in scope at the point of the goto.
6766 For instance, this example:
6767 </p>
6768
6769 <pre>
6770         goto L  // BAD
6771         v := 3
6772 L:
6773 </pre>
6774
6775 <p>
6776 is erroneous because the jump to label <code>L</code> skips
6777 the creation of <code>v</code>.
6778 </p>
6779
6780 <p>
6781 A "goto" statement outside a <a href="#Blocks">block</a> cannot jump to a label inside that block.
6782 For instance, this example:
6783 </p>
6784
6785 <pre>
6786 if n%2 == 1 {
6787         goto L1
6788 }
6789 for n &gt; 0 {
6790         f()
6791         n--
6792 L1:
6793         f()
6794         n--
6795 }
6796 </pre>
6797
6798 <p>
6799 is erroneous because the label <code>L1</code> is inside
6800 the "for" statement's block but the <code>goto</code> is not.
6801 </p>
6802
6803 <h3 id="Fallthrough_statements">Fallthrough statements</h3>
6804
6805 <p>
6806 A "fallthrough" statement transfers control to the first statement of the
6807 next case clause in an <a href="#Expression_switches">expression "switch" statement</a>.
6808 It may be used only as the final non-empty statement in such a clause.
6809 </p>
6810
6811 <pre class="ebnf">
6812 FallthroughStmt = "fallthrough" .
6813 </pre>
6814
6815
6816 <h3 id="Defer_statements">Defer statements</h3>
6817
6818 <p>
6819 A "defer" statement invokes a function whose execution is deferred
6820 to the moment the surrounding function returns, either because the
6821 surrounding function executed a <a href="#Return_statements">return statement</a>,
6822 reached the end of its <a href="#Function_declarations">function body</a>,
6823 or because the corresponding goroutine is <a href="#Handling_panics">panicking</a>.
6824 </p>
6825
6826 <pre class="ebnf">
6827 DeferStmt = "defer" Expression .
6828 </pre>
6829
6830 <p>
6831 The expression must be a function or method call; it cannot be parenthesized.
6832 Calls of built-in functions are restricted as for
6833 <a href="#Expression_statements">expression statements</a>.
6834 </p>
6835
6836 <p>
6837 Each time a "defer" statement
6838 executes, the function value and parameters to the call are
6839 <a href="#Calls">evaluated as usual</a>
6840 and saved anew but the actual function is not invoked.
6841 Instead, deferred functions are invoked immediately before
6842 the surrounding function returns, in the reverse order
6843 they were deferred. That is, if the surrounding function
6844 returns through an explicit <a href="#Return_statements">return statement</a>,
6845 deferred functions are executed <i>after</i> any result parameters are set
6846 by that return statement but <i>before</i> the function returns to its caller.
6847 If a deferred function value evaluates
6848 to <code>nil</code>, execution <a href="#Handling_panics">panics</a>
6849 when the function is invoked, not when the "defer" statement is executed.
6850 </p>
6851
6852 <p>
6853 For instance, if the deferred function is
6854 a <a href="#Function_literals">function literal</a> and the surrounding
6855 function has <a href="#Function_types">named result parameters</a> that
6856 are in scope within the literal, the deferred function may access and modify
6857 the result parameters before they are returned.
6858 If the deferred function has any return values, they are discarded when
6859 the function completes.
6860 (See also the section on <a href="#Handling_panics">handling panics</a>.)
6861 </p>
6862
6863 <pre>
6864 lock(l)
6865 defer unlock(l)  // unlocking happens before surrounding function returns
6866
6867 // prints 3 2 1 0 before surrounding function returns
6868 for i := 0; i &lt;= 3; i++ {
6869         defer fmt.Print(i)
6870 }
6871
6872 // f returns 42
6873 func f() (result int) {
6874         defer func() {
6875                 // result is accessed after it was set to 6 by the return statement
6876                 result *= 7
6877         }()
6878         return 6
6879 }
6880 </pre>
6881
6882 <h2 id="Built-in_functions">Built-in functions</h2>
6883
6884 <p>
6885 Built-in functions are
6886 <a href="#Predeclared_identifiers">predeclared</a>.
6887 They are called like any other function but some of them
6888 accept a type instead of an expression as the first argument.
6889 </p>
6890
6891 <p>
6892 The built-in functions do not have standard Go types,
6893 so they can only appear in <a href="#Calls">call expressions</a>;
6894 they cannot be used as function values.
6895 </p>
6896
6897 <h3 id="Close">Close</h3>
6898
6899 <p>
6900 For a channel <code>c</code>, the built-in function <code>close(c)</code>
6901 records that no more values will be sent on the channel.
6902 It is an error if <code>c</code> is a receive-only channel.
6903 Sending to or closing a closed channel causes a <a href="#Run_time_panics">run-time panic</a>.
6904 Closing the nil channel also causes a <a href="#Run_time_panics">run-time panic</a>.
6905 After calling <code>close</code>, and after any previously
6906 sent values have been received, receive operations will return
6907 the zero value for the channel's type without blocking.
6908 The multi-valued <a href="#Receive_operator">receive operation</a>
6909 returns a received value along with an indication of whether the channel is closed.
6910 </p>
6911
6912 <h3 id="Length_and_capacity">Length and capacity</h3>
6913
6914 <p>
6915 The built-in functions <code>len</code> and <code>cap</code> take arguments
6916 of various types and return a result of type <code>int</code>.
6917 The implementation guarantees that the result always fits into an <code>int</code>.
6918 </p>
6919
6920 <pre class="grammar">
6921 Call      Argument type    Result
6922
6923 len(s)    string type      string length in bytes
6924           [n]T, *[n]T      array length (== n)
6925           []T              slice length
6926           map[K]T          map length (number of defined keys)
6927           chan T           number of elements queued in channel buffer
6928           type parameter   see below
6929
6930 cap(s)    [n]T, *[n]T      array length (== n)
6931           []T              slice capacity
6932           chan T           channel buffer capacity
6933           type parameter   see below
6934 </pre>
6935
6936 <p>
6937 If the argument type is a <a href="#Type_parameters">type parameter</a> <code>P</code>,
6938 <code>P</code> must have <a href="#Structure of interfaces">specific types</a>, and
6939 the call <code>len(e)</code> (or <code>cap(e)</code> respectively) must be valid for
6940 each specific type of <code>P</code>.
6941 The result is the length (or capacity, respectively) of the argument whose type
6942 corresponds to the type argument with which <code>P</code> was
6943 <a href="#Instantiations">instantiated</a>.
6944 </p>
6945
6946 <p>
6947 The capacity of a slice is the number of elements for which there is
6948 space allocated in the underlying array.
6949 At any time the following relationship holds:
6950 </p>
6951
6952 <pre>
6953 0 &lt;= len(s) &lt;= cap(s)
6954 </pre>
6955
6956 <p>
6957 The length of a <code>nil</code> slice, map or channel is 0.
6958 The capacity of a <code>nil</code> slice or channel is 0.
6959 </p>
6960
6961 <p>
6962 The expression <code>len(s)</code> is <a href="#Constants">constant</a> if
6963 <code>s</code> is a string constant. The expressions <code>len(s)</code> and
6964 <code>cap(s)</code> are constants if the type of <code>s</code> is an array
6965 or pointer to an array and the expression <code>s</code> does not contain
6966 <a href="#Receive_operator">channel receives</a> or (non-constant)
6967 <a href="#Calls">function calls</a>; in this case <code>s</code> is not evaluated.
6968 Otherwise, invocations of <code>len</code> and <code>cap</code> are not
6969 constant and <code>s</code> is evaluated.
6970 </p>
6971
6972 <pre>
6973 const (
6974         c1 = imag(2i)                    // imag(2i) = 2.0 is a constant
6975         c2 = len([10]float64{2})         // [10]float64{2} contains no function calls
6976         c3 = len([10]float64{c1})        // [10]float64{c1} contains no function calls
6977         c4 = len([10]float64{imag(2i)})  // imag(2i) is a constant and no function call is issued
6978         c5 = len([10]float64{imag(z)})   // invalid: imag(z) is a (non-constant) function call
6979 )
6980 var z complex128
6981 </pre>
6982
6983 <h3 id="Allocation">Allocation</h3>
6984
6985 <p>
6986 The built-in function <code>new</code> takes a type <code>T</code>,
6987 allocates storage for a <a href="#Variables">variable</a> of that type
6988 at run time, and returns a value of type <code>*T</code>
6989 <a href="#Pointer_types">pointing</a> to it.
6990 The variable is initialized as described in the section on
6991 <a href="#The_zero_value">initial values</a>.
6992 </p>
6993
6994 <pre class="grammar">
6995 new(T)
6996 </pre>
6997
6998 <p>
6999 For instance
7000 </p>
7001
7002 <pre>
7003 type S struct { a int; b float64 }
7004 new(S)
7005 </pre>
7006
7007 <p>
7008 allocates storage for a variable of type <code>S</code>,
7009 initializes it (<code>a=0</code>, <code>b=0.0</code>),
7010 and returns a value of type <code>*S</code> containing the address
7011 of the location.
7012 </p>
7013
7014 <h3 id="Making_slices_maps_and_channels">Making slices, maps and channels</h3>
7015
7016 <p>
7017 The built-in function <code>make</code> takes a type <code>T</code>,
7018 which must be a slice, map or channel type,
7019 optionally followed by a type-specific list of expressions.
7020 It returns a value of type <code>T</code> (not <code>*T</code>).
7021 The memory is initialized as described in the section on
7022 <a href="#The_zero_value">initial values</a>.
7023 </p>
7024
7025 <pre class="grammar">
7026 Call             Type T     Result
7027
7028 make(T, n)       slice      slice of type T with length n and capacity n
7029 make(T, n, m)    slice      slice of type T with length n and capacity m
7030
7031 make(T)          map        map of type T
7032 make(T, n)       map        map of type T with initial space for approximately n elements
7033
7034 make(T)          channel    unbuffered channel of type T
7035 make(T, n)       channel    buffered channel of type T, buffer size n
7036 </pre>
7037
7038
7039 <p>
7040 Each of the size arguments <code>n</code> and <code>m</code> must be of integer type
7041 or an untyped <a href="#Constants">constant</a>.
7042 A constant size argument must be non-negative and <a href="#Representability">representable</a>
7043 by a value of type <code>int</code>; if it is an untyped constant it is given type <code>int</code>.
7044 If both <code>n</code> and <code>m</code> are provided and are constant, then
7045 <code>n</code> must be no larger than <code>m</code>.
7046 If <code>n</code> is negative or larger than <code>m</code> at run time,
7047 a <a href="#Run_time_panics">run-time panic</a> occurs.
7048 </p>
7049
7050 <pre>
7051 s := make([]int, 10, 100)       // slice with len(s) == 10, cap(s) == 100
7052 s := make([]int, 1e3)           // slice with len(s) == cap(s) == 1000
7053 s := make([]int, 1&lt;&lt;63)         // illegal: len(s) is not representable by a value of type int
7054 s := make([]int, 10, 0)         // illegal: len(s) > cap(s)
7055 c := make(chan int, 10)         // channel with a buffer size of 10
7056 m := make(map[string]int, 100)  // map with initial space for approximately 100 elements
7057 </pre>
7058
7059 <p>
7060 Calling <code>make</code> with a map type and size hint <code>n</code> will
7061 create a map with initial space to hold <code>n</code> map elements.
7062 The precise behavior is implementation-dependent.
7063 </p>
7064
7065
7066 <h3 id="Appending_and_copying_slices">Appending to and copying slices</h3>
7067
7068 <p>
7069 The built-in functions <code>append</code> and <code>copy</code> assist in
7070 common slice operations.
7071 For both functions, the result is independent of whether the memory referenced
7072 by the arguments overlaps.
7073 </p>
7074
7075 <p>
7076 The <a href="#Function_types">variadic</a> function <code>append</code>
7077 appends zero or more values <code>x</code>
7078 to <code>s</code> of type <code>S</code>, which must be a slice type, and
7079 returns the resulting slice, also of type <code>S</code>.
7080 The values <code>x</code> are passed to a parameter of type <code>...T</code>
7081 where <code>T</code> is the <a href="#Slice_types">element type</a> of
7082 <code>S</code> and the respective
7083 <a href="#Passing_arguments_to_..._parameters">parameter passing rules</a> apply.
7084 As a special case, <code>append</code> also accepts a first argument
7085 assignable to type <code>[]byte</code> with a second argument of
7086 string type followed by <code>...</code>. This form appends the
7087 bytes of the string.
7088 </p>
7089
7090 <pre class="grammar">
7091 append(s S, x ...T) S  // T is the element type of S
7092 </pre>
7093
7094 <p>
7095 If the capacity of <code>s</code> is not large enough to fit the additional
7096 values, <code>append</code> allocates a new, sufficiently large underlying
7097 array that fits both the existing slice elements and the additional values.
7098 Otherwise, <code>append</code> re-uses the underlying array.
7099 </p>
7100
7101 <pre>
7102 s0 := []int{0, 0}
7103 s1 := append(s0, 2)                // append a single element     s1 == []int{0, 0, 2}
7104 s2 := append(s1, 3, 5, 7)          // append multiple elements    s2 == []int{0, 0, 2, 3, 5, 7}
7105 s3 := append(s2, s0...)            // append a slice              s3 == []int{0, 0, 2, 3, 5, 7, 0, 0}
7106 s4 := append(s3[3:6], s3[2:]...)   // append overlapping slice    s4 == []int{3, 5, 7, 2, 3, 5, 7, 0, 0}
7107
7108 var t []interface{}
7109 t = append(t, 42, 3.1415, "foo")   //                             t == []interface{}{42, 3.1415, "foo"}
7110
7111 var b []byte
7112 b = append(b, "bar"...)            // append string contents      b == []byte{'b', 'a', 'r' }
7113 </pre>
7114
7115 <p>
7116 The function <code>copy</code> copies slice elements from
7117 a source <code>src</code> to a destination <code>dst</code> and returns the
7118 number of elements copied.
7119 Both arguments must have <a href="#Type_identity">identical</a> element type <code>T</code> and must be
7120 <a href="#Assignability">assignable</a> to a slice of type <code>[]T</code>.
7121 The number of elements copied is the minimum of
7122 <code>len(src)</code> and <code>len(dst)</code>.
7123 As a special case, <code>copy</code> also accepts a destination argument assignable
7124 to type <code>[]byte</code> with a source argument of a string type.
7125 This form copies the bytes from the string into the byte slice.
7126 </p>
7127
7128 <pre class="grammar">
7129 copy(dst, src []T) int
7130 copy(dst []byte, src string) int
7131 </pre>
7132
7133 <p>
7134 Examples:
7135 </p>
7136
7137 <pre>
7138 var a = [...]int{0, 1, 2, 3, 4, 5, 6, 7}
7139 var s = make([]int, 6)
7140 var b = make([]byte, 5)
7141 n1 := copy(s, a[0:])            // n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
7142 n2 := copy(s, s[2:])            // n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
7143 n3 := copy(b, "Hello, World!")  // n3 == 5, b == []byte("Hello")
7144 </pre>
7145
7146
7147 <h3 id="Deletion_of_map_elements">Deletion of map elements</h3>
7148
7149 <p>
7150 The built-in function <code>delete</code> removes the element with key
7151 <code>k</code> from a <a href="#Map_types">map</a> <code>m</code>. The
7152 type of <code>k</code> must be <a href="#Assignability">assignable</a>
7153 to the key type of <code>m</code>.
7154 </p>
7155
7156 <pre class="grammar">
7157 delete(m, k)  // remove element m[k] from map m
7158 </pre>
7159
7160 <p>
7161 If the map <code>m</code> is <code>nil</code> or the element <code>m[k]</code>
7162 does not exist, <code>delete</code> is a no-op.
7163 </p>
7164
7165
7166 <h3 id="Complex_numbers">Manipulating complex numbers</h3>
7167
7168 <p>
7169 Three functions assemble and disassemble complex numbers.
7170 The built-in function <code>complex</code> constructs a complex
7171 value from a floating-point real and imaginary part, while
7172 <code>real</code> and <code>imag</code>
7173 extract the real and imaginary parts of a complex value.
7174 </p>
7175
7176 <pre class="grammar">
7177 complex(realPart, imaginaryPart floatT) complexT
7178 real(complexT) floatT
7179 imag(complexT) floatT
7180 </pre>
7181
7182 <p>
7183 The type of the arguments and return value correspond.
7184 For <code>complex</code>, the two arguments must be of the same
7185 floating-point type and the return type is the complex type
7186 with the corresponding floating-point constituents:
7187 <code>complex64</code> for <code>float32</code> arguments, and
7188 <code>complex128</code> for <code>float64</code> arguments.
7189 If one of the arguments evaluates to an untyped constant, it is first implicitly
7190 <a href="#Conversions">converted</a> to the type of the other argument.
7191 If both arguments evaluate to untyped constants, they must be non-complex
7192 numbers or their imaginary parts must be zero, and the return value of
7193 the function is an untyped complex constant.
7194 </p>
7195
7196 <p>
7197 For <code>real</code> and <code>imag</code>, the argument must be
7198 of complex type, and the return type is the corresponding floating-point
7199 type: <code>float32</code> for a <code>complex64</code> argument, and
7200 <code>float64</code> for a <code>complex128</code> argument.
7201 If the argument evaluates to an untyped constant, it must be a number,
7202 and the return value of the function is an untyped floating-point constant.
7203 </p>
7204
7205 <p>
7206 The <code>real</code> and <code>imag</code> functions together form the inverse of
7207 <code>complex</code>, so for a value <code>z</code> of a complex type <code>Z</code>,
7208 <code>z&nbsp;==&nbsp;Z(complex(real(z),&nbsp;imag(z)))</code>.
7209 </p>
7210
7211 <p>
7212 If the operands of these functions are all constants, the return
7213 value is a constant.
7214 </p>
7215
7216 <pre>
7217 var a = complex(2, -2)             // complex128
7218 const b = complex(1.0, -1.4)       // untyped complex constant 1 - 1.4i
7219 x := float32(math.Cos(math.Pi/2))  // float32
7220 var c64 = complex(5, -x)           // complex64
7221 var s int = complex(1, 0)          // untyped complex constant 1 + 0i can be converted to int
7222 _ = complex(1, 2&lt;&lt;s)               // illegal: 2 assumes floating-point type, cannot shift
7223 var rl = real(c64)                 // float32
7224 var im = imag(a)                   // float64
7225 const c = imag(b)                  // untyped constant -1.4
7226 _ = imag(3 &lt;&lt; s)                   // illegal: 3 assumes complex type, cannot shift
7227 </pre>
7228
7229 <h3 id="Handling_panics">Handling panics</h3>
7230
7231 <p> Two built-in functions, <code>panic</code> and <code>recover</code>,
7232 assist in reporting and handling <a href="#Run_time_panics">run-time panics</a>
7233 and program-defined error conditions.
7234 </p>
7235
7236 <pre class="grammar">
7237 func panic(interface{})
7238 func recover() interface{}
7239 </pre>
7240
7241 <p>
7242 While executing a function <code>F</code>,
7243 an explicit call to <code>panic</code> or a <a href="#Run_time_panics">run-time panic</a>
7244 terminates the execution of <code>F</code>.
7245 Any functions <a href="#Defer_statements">deferred</a> by <code>F</code>
7246 are then executed as usual.
7247 Next, any deferred functions run by <code>F's</code> caller are run,
7248 and so on up to any deferred by the top-level function in the executing goroutine.
7249 At that point, the program is terminated and the error
7250 condition is reported, including the value of the argument to <code>panic</code>.
7251 This termination sequence is called <i>panicking</i>.
7252 </p>
7253
7254 <pre>
7255 panic(42)
7256 panic("unreachable")
7257 panic(Error("cannot parse"))
7258 </pre>
7259
7260 <p>
7261 The <code>recover</code> function allows a program to manage behavior
7262 of a panicking goroutine.
7263 Suppose a function <code>G</code> defers a function <code>D</code> that calls
7264 <code>recover</code> and a panic occurs in a function on the same goroutine in which <code>G</code>
7265 is executing.
7266 When the running of deferred functions reaches <code>D</code>,
7267 the return value of <code>D</code>'s call to <code>recover</code> will be the value passed to the call of <code>panic</code>.
7268 If <code>D</code> returns normally, without starting a new
7269 <code>panic</code>, the panicking sequence stops. In that case,
7270 the state of functions called between <code>G</code> and the call to <code>panic</code>
7271 is discarded, and normal execution resumes.
7272 Any functions deferred by <code>G</code> before <code>D</code> are then run and <code>G</code>'s
7273 execution terminates by returning to its caller.
7274 </p>
7275
7276 <p>
7277 The return value of <code>recover</code> is <code>nil</code> if any of the following conditions holds:
7278 </p>
7279 <ul>
7280 <li>
7281 <code>panic</code>'s argument was <code>nil</code>;
7282 </li>
7283 <li>
7284 the goroutine is not panicking;
7285 </li>
7286 <li>
7287 <code>recover</code> was not called directly by a deferred function.
7288 </li>
7289 </ul>
7290
7291 <p>
7292 The <code>protect</code> function in the example below invokes
7293 the function argument <code>g</code> and protects callers from
7294 run-time panics raised by <code>g</code>.
7295 </p>
7296
7297 <pre>
7298 func protect(g func()) {
7299         defer func() {
7300                 log.Println("done")  // Println executes normally even if there is a panic
7301                 if x := recover(); x != nil {
7302                         log.Printf("run time panic: %v", x)
7303                 }
7304         }()
7305         log.Println("start")
7306         g()
7307 }
7308 </pre>
7309
7310
7311 <h3 id="Bootstrapping">Bootstrapping</h3>
7312
7313 <p>
7314 Current implementations provide several built-in functions useful during
7315 bootstrapping. These functions are documented for completeness but are not
7316 guaranteed to stay in the language. They do not return a result.
7317 </p>
7318
7319 <pre class="grammar">
7320 Function   Behavior
7321
7322 print      prints all arguments; formatting of arguments is implementation-specific
7323 println    like print but prints spaces between arguments and a newline at the end
7324 </pre>
7325
7326 <p>
7327 Implementation restriction: <code>print</code> and <code>println</code> need not
7328 accept arbitrary argument types, but printing of boolean, numeric, and string
7329 <a href="#Types">types</a> must be supported.
7330 </p>
7331
7332 <h2 id="Packages">Packages</h2>
7333
7334 <p>
7335 Go programs are constructed by linking together <i>packages</i>.
7336 A package in turn is constructed from one or more source files
7337 that together declare constants, types, variables and functions
7338 belonging to the package and which are accessible in all files
7339 of the same package. Those elements may be
7340 <a href="#Exported_identifiers">exported</a> and used in another package.
7341 </p>
7342
7343 <h3 id="Source_file_organization">Source file organization</h3>
7344
7345 <p>
7346 Each source file consists of a package clause defining the package
7347 to which it belongs, followed by a possibly empty set of import
7348 declarations that declare packages whose contents it wishes to use,
7349 followed by a possibly empty set of declarations of functions,
7350 types, variables, and constants.
7351 </p>
7352
7353 <pre class="ebnf">
7354 SourceFile       = PackageClause ";" { ImportDecl ";" } { TopLevelDecl ";" } .
7355 </pre>
7356
7357 <h3 id="Package_clause">Package clause</h3>
7358
7359 <p>
7360 A package clause begins each source file and defines the package
7361 to which the file belongs.
7362 </p>
7363
7364 <pre class="ebnf">
7365 PackageClause  = "package" PackageName .
7366 PackageName    = identifier .
7367 </pre>
7368
7369 <p>
7370 The PackageName must not be the <a href="#Blank_identifier">blank identifier</a>.
7371 </p>
7372
7373 <pre>
7374 package math
7375 </pre>
7376
7377 <p>
7378 A set of files sharing the same PackageName form the implementation of a package.
7379 An implementation may require that all source files for a package inhabit the same directory.
7380 </p>
7381
7382 <h3 id="Import_declarations">Import declarations</h3>
7383
7384 <p>
7385 An import declaration states that the source file containing the declaration
7386 depends on functionality of the <i>imported</i> package
7387 (<a href="#Program_initialization_and_execution">§Program initialization and execution</a>)
7388 and enables access to <a href="#Exported_identifiers">exported</a> identifiers
7389 of that package.
7390 The import names an identifier (PackageName) to be used for access and an ImportPath
7391 that specifies the package to be imported.
7392 </p>
7393
7394 <pre class="ebnf">
7395 ImportDecl       = "import" ( ImportSpec | "(" { ImportSpec ";" } ")" ) .
7396 ImportSpec       = [ "." | PackageName ] ImportPath .
7397 ImportPath       = string_lit .
7398 </pre>
7399
7400 <p>
7401 The PackageName is used in <a href="#Qualified_identifiers">qualified identifiers</a>
7402 to access exported identifiers of the package within the importing source file.
7403 It is declared in the <a href="#Blocks">file block</a>.
7404 If the PackageName is omitted, it defaults to the identifier specified in the
7405 <a href="#Package_clause">package clause</a> of the imported package.
7406 If an explicit period (<code>.</code>) appears instead of a name, all the
7407 package's exported identifiers declared in that package's
7408 <a href="#Blocks">package block</a> will be declared in the importing source
7409 file's file block and must be accessed without a qualifier.
7410 </p>
7411
7412 <p>
7413 The interpretation of the ImportPath is implementation-dependent but
7414 it is typically a substring of the full file name of the compiled
7415 package and may be relative to a repository of installed packages.
7416 </p>
7417
7418 <p>
7419 Implementation restriction: A compiler may restrict ImportPaths to
7420 non-empty strings using only characters belonging to
7421 <a href="https://www.unicode.org/versions/Unicode6.3.0/">Unicode's</a>
7422 L, M, N, P, and S general categories (the Graphic characters without
7423 spaces) and may also exclude the characters
7424 <code>!"#$%&amp;'()*,:;&lt;=&gt;?[\]^`{|}</code>
7425 and the Unicode replacement character U+FFFD.
7426 </p>
7427
7428 <p>
7429 Assume we have compiled a package containing the package clause
7430 <code>package math</code>, which exports function <code>Sin</code>, and
7431 installed the compiled package in the file identified by
7432 <code>"lib/math"</code>.
7433 This table illustrates how <code>Sin</code> is accessed in files
7434 that import the package after the
7435 various types of import declaration.
7436 </p>
7437
7438 <pre class="grammar">
7439 Import declaration          Local name of Sin
7440
7441 import   "lib/math"         math.Sin
7442 import m "lib/math"         m.Sin
7443 import . "lib/math"         Sin
7444 </pre>
7445
7446 <p>
7447 An import declaration declares a dependency relation between
7448 the importing and imported package.
7449 It is illegal for a package to import itself, directly or indirectly,
7450 or to directly import a package without
7451 referring to any of its exported identifiers. To import a package solely for
7452 its side-effects (initialization), use the <a href="#Blank_identifier">blank</a>
7453 identifier as explicit package name:
7454 </p>
7455
7456 <pre>
7457 import _ "lib/math"
7458 </pre>
7459
7460
7461 <h3 id="An_example_package">An example package</h3>
7462
7463 <p>
7464 Here is a complete Go package that implements a concurrent prime sieve.
7465 </p>
7466
7467 <pre>
7468 package main
7469
7470 import "fmt"
7471
7472 // Send the sequence 2, 3, 4, … to channel 'ch'.
7473 func generate(ch chan&lt;- int) {
7474         for i := 2; ; i++ {
7475                 ch &lt;- i  // Send 'i' to channel 'ch'.
7476         }
7477 }
7478
7479 // Copy the values from channel 'src' to channel 'dst',
7480 // removing those divisible by 'prime'.
7481 func filter(src &lt;-chan int, dst chan&lt;- int, prime int) {
7482         for i := range src {  // Loop over values received from 'src'.
7483                 if i%prime != 0 {
7484                         dst &lt;- i  // Send 'i' to channel 'dst'.
7485                 }
7486         }
7487 }
7488
7489 // The prime sieve: Daisy-chain filter processes together.
7490 func sieve() {
7491         ch := make(chan int)  // Create a new channel.
7492         go generate(ch)       // Start generate() as a subprocess.
7493         for {
7494                 prime := &lt;-ch
7495                 fmt.Print(prime, "\n")
7496                 ch1 := make(chan int)
7497                 go filter(ch, ch1, prime)
7498                 ch = ch1
7499         }
7500 }
7501
7502 func main() {
7503         sieve()
7504 }
7505 </pre>
7506
7507 <h2 id="Program_initialization_and_execution">Program initialization and execution</h2>
7508
7509 <h3 id="The_zero_value">The zero value</h3>
7510 <p>
7511 When storage is allocated for a <a href="#Variables">variable</a>,
7512 either through a declaration or a call of <code>new</code>, or when
7513 a new value is created, either through a composite literal or a call
7514 of <code>make</code>,
7515 and no explicit initialization is provided, the variable or value is
7516 given a default value.  Each element of such a variable or value is
7517 set to the <i>zero value</i> for its type: <code>false</code> for booleans,
7518 <code>0</code> for numeric types, <code>""</code>
7519 for strings, and <code>nil</code> for pointers, functions, interfaces, slices, channels, and maps.
7520 This initialization is done recursively, so for instance each element of an
7521 array of structs will have its fields zeroed if no value is specified.
7522 </p>
7523 <p>
7524 These two simple declarations are equivalent:
7525 </p>
7526
7527 <pre>
7528 var i int
7529 var i int = 0
7530 </pre>
7531
7532 <p>
7533 After
7534 </p>
7535
7536 <pre>
7537 type T struct { i int; f float64; next *T }
7538 t := new(T)
7539 </pre>
7540
7541 <p>
7542 the following holds:
7543 </p>
7544
7545 <pre>
7546 t.i == 0
7547 t.f == 0.0
7548 t.next == nil
7549 </pre>
7550
7551 <p>
7552 The same would also be true after
7553 </p>
7554
7555 <pre>
7556 var t T
7557 </pre>
7558
7559 <h3 id="Package_initialization">Package initialization</h3>
7560
7561 <p>
7562 Within a package, package-level variable initialization proceeds stepwise,
7563 with each step selecting the variable earliest in <i>declaration order</i>
7564 which has no dependencies on uninitialized variables.
7565 </p>
7566
7567 <p>
7568 More precisely, a package-level variable is considered <i>ready for
7569 initialization</i> if it is not yet initialized and either has
7570 no <a href="#Variable_declarations">initialization expression</a> or
7571 its initialization expression has no <i>dependencies</i> on uninitialized variables.
7572 Initialization proceeds by repeatedly initializing the next package-level
7573 variable that is earliest in declaration order and ready for initialization,
7574 until there are no variables ready for initialization.
7575 </p>
7576
7577 <p>
7578 If any variables are still uninitialized when this
7579 process ends, those variables are part of one or more initialization cycles,
7580 and the program is not valid.
7581 </p>
7582
7583 <p>
7584 Multiple variables on the left-hand side of a variable declaration initialized
7585 by single (multi-valued) expression on the right-hand side are initialized
7586 together: If any of the variables on the left-hand side is initialized, all
7587 those variables are initialized in the same step.
7588 </p>
7589
7590 <pre>
7591 var x = a
7592 var a, b = f() // a and b are initialized together, before x is initialized
7593 </pre>
7594
7595 <p>
7596 For the purpose of package initialization, <a href="#Blank_identifier">blank</a>
7597 variables are treated like any other variables in declarations.
7598 </p>
7599
7600 <p>
7601 The declaration order of variables declared in multiple files is determined
7602 by the order in which the files are presented to the compiler: Variables
7603 declared in the first file are declared before any of the variables declared
7604 in the second file, and so on.
7605 </p>
7606
7607 <p>
7608 Dependency analysis does not rely on the actual values of the
7609 variables, only on lexical <i>references</i> to them in the source,
7610 analyzed transitively. For instance, if a variable <code>x</code>'s
7611 initialization expression refers to a function whose body refers to
7612 variable <code>y</code> then <code>x</code> depends on <code>y</code>.
7613 Specifically:
7614 </p>
7615
7616 <ul>
7617 <li>
7618 A reference to a variable or function is an identifier denoting that
7619 variable or function.
7620 </li>
7621
7622 <li>
7623 A reference to a method <code>m</code> is a
7624 <a href="#Method_values">method value</a> or
7625 <a href="#Method_expressions">method expression</a> of the form
7626 <code>t.m</code>, where the (static) type of <code>t</code> is
7627 not an interface type, and the method <code>m</code> is in the
7628 <a href="#Method_sets">method set</a> of <code>t</code>.
7629 It is immaterial whether the resulting function value
7630 <code>t.m</code> is invoked.
7631 </li>
7632
7633 <li>
7634 A variable, function, or method <code>x</code> depends on a variable
7635 <code>y</code> if <code>x</code>'s initialization expression or body
7636 (for functions and methods) contains a reference to <code>y</code>
7637 or to a function or method that depends on <code>y</code>.
7638 </li>
7639 </ul>
7640
7641 <p>
7642 For example, given the declarations
7643 </p>
7644
7645 <pre>
7646 var (
7647         a = c + b  // == 9
7648         b = f()    // == 4
7649         c = f()    // == 5
7650         d = 3      // == 5 after initialization has finished
7651 )
7652
7653 func f() int {
7654         d++
7655         return d
7656 }
7657 </pre>
7658
7659 <p>
7660 the initialization order is <code>d</code>, <code>b</code>, <code>c</code>, <code>a</code>.
7661 Note that the order of subexpressions in initialization expressions is irrelevant:
7662 <code>a = c + b</code> and <code>a = b + c</code> result in the same initialization
7663 order in this example.
7664 </p>
7665
7666 <p>
7667 Dependency analysis is performed per package; only references referring
7668 to variables, functions, and (non-interface) methods declared in the current
7669 package are considered. If other, hidden, data dependencies exists between
7670 variables, the initialization order between those variables is unspecified.
7671 </p>
7672
7673 <p>
7674 For instance, given the declarations
7675 </p>
7676
7677 <pre>
7678 var x = I(T{}).ab()   // x has an undetected, hidden dependency on a and b
7679 var _ = sideEffect()  // unrelated to x, a, or b
7680 var a = b
7681 var b = 42
7682
7683 type I interface      { ab() []int }
7684 type T struct{}
7685 func (T) ab() []int   { return []int{a, b} }
7686 </pre>
7687
7688 <p>
7689 the variable <code>a</code> will be initialized after <code>b</code> but
7690 whether <code>x</code> is initialized before <code>b</code>, between
7691 <code>b</code> and <code>a</code>, or after <code>a</code>, and
7692 thus also the moment at which <code>sideEffect()</code> is called (before
7693 or after <code>x</code> is initialized) is not specified.
7694 </p>
7695
7696 <p>
7697 Variables may also be initialized using functions named <code>init</code>
7698 declared in the package block, with no arguments and no result parameters.
7699 </p>
7700
7701 <pre>
7702 func init() { … }
7703 </pre>
7704
7705 <p>
7706 Multiple such functions may be defined per package, even within a single
7707 source file. In the package block, the <code>init</code> identifier can
7708 be used only to declare <code>init</code> functions, yet the identifier
7709 itself is not <a href="#Declarations_and_scope">declared</a>. Thus
7710 <code>init</code> functions cannot be referred to from anywhere
7711 in a program.
7712 </p>
7713
7714 <p>
7715 A package with no imports is initialized by assigning initial values
7716 to all its package-level variables followed by calling all <code>init</code>
7717 functions in the order they appear in the source, possibly in multiple files,
7718 as presented to the compiler.
7719 If a package has imports, the imported packages are initialized
7720 before initializing the package itself. If multiple packages import
7721 a package, the imported package will be initialized only once.
7722 The importing of packages, by construction, guarantees that there
7723 can be no cyclic initialization dependencies.
7724 </p>
7725
7726 <p>
7727 Package initialization&mdash;variable initialization and the invocation of
7728 <code>init</code> functions&mdash;happens in a single goroutine,
7729 sequentially, one package at a time.
7730 An <code>init</code> function may launch other goroutines, which can run
7731 concurrently with the initialization code. However, initialization
7732 always sequences
7733 the <code>init</code> functions: it will not invoke the next one
7734 until the previous one has returned.
7735 </p>
7736
7737 <p>
7738 To ensure reproducible initialization behavior, build systems are encouraged
7739 to present multiple files belonging to the same package in lexical file name
7740 order to a compiler.
7741 </p>
7742
7743
7744 <h3 id="Program_execution">Program execution</h3>
7745 <p>
7746 A complete program is created by linking a single, unimported package
7747 called the <i>main package</i> with all the packages it imports, transitively.
7748 The main package must
7749 have package name <code>main</code> and
7750 declare a function <code>main</code> that takes no
7751 arguments and returns no value.
7752 </p>
7753
7754 <pre>
7755 func main() { … }
7756 </pre>
7757
7758 <p>
7759 Program execution begins by initializing the main package and then
7760 invoking the function <code>main</code>.
7761 When that function invocation returns, the program exits.
7762 It does not wait for other (non-<code>main</code>) goroutines to complete.
7763 </p>
7764
7765 <h2 id="Errors">Errors</h2>
7766
7767 <p>
7768 The predeclared type <code>error</code> is defined as
7769 </p>
7770
7771 <pre>
7772 type error interface {
7773         Error() string
7774 }
7775 </pre>
7776
7777 <p>
7778 It is the conventional interface for representing an error condition,
7779 with the nil value representing no error.
7780 For instance, a function to read data from a file might be defined:
7781 </p>
7782
7783 <pre>
7784 func Read(f *File, b []byte) (n int, err error)
7785 </pre>
7786
7787 <h2 id="Run_time_panics">Run-time panics</h2>
7788
7789 <p>
7790 Execution errors such as attempting to index an array out
7791 of bounds trigger a <i>run-time panic</i> equivalent to a call of
7792 the built-in function <a href="#Handling_panics"><code>panic</code></a>
7793 with a value of the implementation-defined interface type <code>runtime.Error</code>.
7794 That type satisfies the predeclared interface type
7795 <a href="#Errors"><code>error</code></a>.
7796 The exact error values that
7797 represent distinct run-time error conditions are unspecified.
7798 </p>
7799
7800 <pre>
7801 package runtime
7802
7803 type Error interface {
7804         error
7805         // and perhaps other methods
7806 }
7807 </pre>
7808
7809 <h2 id="System_considerations">System considerations</h2>
7810
7811 <h3 id="Package_unsafe">Package <code>unsafe</code></h3>
7812
7813 <p>
7814 The built-in package <code>unsafe</code>, known to the compiler
7815 and accessible through the <a href="#Import_declarations">import path</a> <code>"unsafe"</code>,
7816 provides facilities for low-level programming including operations
7817 that violate the type system. A package using <code>unsafe</code>
7818 must be vetted manually for type safety and may not be portable.
7819 The package provides the following interface:
7820 </p>
7821
7822 <pre class="grammar">
7823 package unsafe
7824
7825 type ArbitraryType int  // shorthand for an arbitrary Go type; it is not a real type
7826 type Pointer *ArbitraryType
7827
7828 func Alignof(variable ArbitraryType) uintptr
7829 func Offsetof(selector ArbitraryType) uintptr
7830 func Sizeof(variable ArbitraryType) uintptr
7831
7832 type IntegerType int  // shorthand for an integer type; it is not a real type
7833 func Add(ptr Pointer, len IntegerType) Pointer
7834 func Slice(ptr *ArbitraryType, len IntegerType) []ArbitraryType
7835 </pre>
7836
7837 <p>
7838 A <code>Pointer</code> is a <a href="#Pointer_types">pointer type</a> but a <code>Pointer</code>
7839 value may not be <a href="#Address_operators">dereferenced</a>.
7840 Any pointer or value of <a href="#Types">underlying type</a> <code>uintptr</code> can be converted to
7841 a type of underlying type <code>Pointer</code> and vice versa.
7842 The effect of converting between <code>Pointer</code> and <code>uintptr</code> is implementation-defined.
7843 </p>
7844
7845 <pre>
7846 var f float64
7847 bits = *(*uint64)(unsafe.Pointer(&amp;f))
7848
7849 type ptr unsafe.Pointer
7850 bits = *(*uint64)(ptr(&amp;f))
7851
7852 var p ptr = nil
7853 </pre>
7854
7855 <p>
7856 The functions <code>Alignof</code> and <code>Sizeof</code> take an expression <code>x</code>
7857 of any type and return the alignment or size, respectively, of a hypothetical variable <code>v</code>
7858 as if <code>v</code> was declared via <code>var v = x</code>.
7859 </p>
7860 <p>
7861 The function <code>Offsetof</code> takes a (possibly parenthesized) <a href="#Selectors">selector</a>
7862 <code>s.f</code>, denoting a field <code>f</code> of the struct denoted by <code>s</code>
7863 or <code>*s</code>, and returns the field offset in bytes relative to the struct's address.
7864 If <code>f</code> is an <a href="#Struct_types">embedded field</a>, it must be reachable
7865 without pointer indirections through fields of the struct.
7866 For a struct <code>s</code> with field <code>f</code>:
7867 </p>
7868
7869 <pre>
7870 uintptr(unsafe.Pointer(&amp;s)) + unsafe.Offsetof(s.f) == uintptr(unsafe.Pointer(&amp;s.f))
7871 </pre>
7872
7873 <p>
7874 Computer architectures may require memory addresses to be <i>aligned</i>;
7875 that is, for addresses of a variable to be a multiple of a factor,
7876 the variable's type's <i>alignment</i>.  The function <code>Alignof</code>
7877 takes an expression denoting a variable of any type and returns the
7878 alignment of the (type of the) variable in bytes.  For a variable
7879 <code>x</code>:
7880 </p>
7881
7882 <pre>
7883 uintptr(unsafe.Pointer(&amp;x)) % unsafe.Alignof(x) == 0
7884 </pre>
7885
7886 <p>
7887 A (variable of) type <code>T</code> has <i>variable size</i> if <code>T</code>
7888 is a type parameter, or if it is an array or struct type containing elements
7889 or fields of variable size. Otherwise the size is <i>constant</i>.
7890 Calls to <code>Alignof</code>, <code>Offsetof</code>, and <code>Sizeof</code>
7891 are compile-time <a href="#Constant_expressions">constant expressions</a> of
7892 type <code>uintptr</code> if their arguments (or the struct <code>s</code> in
7893 the selector expression <code>s.f</code> for <code>Offsetof</code>) are types
7894 of constant size.
7895 </p>
7896
7897 <p>
7898 The function <code>Add</code> adds <code>len</code> to <code>ptr</code>
7899 and returns the updated pointer <code>unsafe.Pointer(uintptr(ptr) + uintptr(len))</code>.
7900 The <code>len</code> argument must be of integer type or an untyped <a href="#Constants">constant</a>.
7901 A constant <code>len</code> argument must be <a href="#Representability">representable</a> by a value of type <code>int</code>;
7902 if it is an untyped constant it is given type <code>int</code>.
7903 The rules for <a href="/pkg/unsafe#Pointer">valid uses</a> of <code>Pointer</code> still apply.
7904 </p>
7905
7906 <p>
7907 The function <code>Slice</code> returns a slice whose underlying array starts at <code>ptr</code>
7908 and whose length and capacity are <code>len</code>.
7909 <code>Slice(ptr, len)</code> is equivalent to
7910 </p>
7911
7912 <pre>
7913 (*[len]ArbitraryType)(unsafe.Pointer(ptr))[:]
7914 </pre>
7915
7916 <p>
7917 except that, as a special case, if <code>ptr</code>
7918 is <code>nil</code> and <code>len</code> is zero,
7919 <code>Slice</code> returns <code>nil</code>.
7920 </p>
7921
7922 <p>
7923 The <code>len</code> argument must be of integer type or an untyped <a href="#Constants">constant</a>.
7924 A constant <code>len</code> argument must be non-negative and <a href="#Representability">representable</a> by a value of type <code>int</code>;
7925 if it is an untyped constant it is given type <code>int</code>.
7926 At run time, if <code>len</code> is negative,
7927 or if <code>ptr</code> is <code>nil</code> and <code>len</code> is not zero,
7928 a <a href="#Run_time_panics">run-time panic</a> occurs.
7929 </p>
7930
7931 <h3 id="Size_and_alignment_guarantees">Size and alignment guarantees</h3>
7932
7933 <p>
7934 For the <a href="#Numeric_types">numeric types</a>, the following sizes are guaranteed:
7935 </p>
7936
7937 <pre class="grammar">
7938 type                                 size in bytes
7939
7940 byte, uint8, int8                     1
7941 uint16, int16                         2
7942 uint32, int32, float32                4
7943 uint64, int64, float64, complex64     8
7944 complex128                           16
7945 </pre>
7946
7947 <p>
7948 The following minimal alignment properties are guaranteed:
7949 </p>
7950 <ol>
7951 <li>For a variable <code>x</code> of any type: <code>unsafe.Alignof(x)</code> is at least 1.
7952 </li>
7953
7954 <li>For a variable <code>x</code> of struct type: <code>unsafe.Alignof(x)</code> is the largest of
7955    all the values <code>unsafe.Alignof(x.f)</code> for each field <code>f</code> of <code>x</code>, but at least 1.
7956 </li>
7957
7958 <li>For a variable <code>x</code> of array type: <code>unsafe.Alignof(x)</code> is the same as
7959         the alignment of a variable of the array's element type.
7960 </li>
7961 </ol>
7962
7963 <p>
7964 A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory.
7965 </p>