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