| <!-- | |
| Biggest open issues: | |
| [ ] General iterators | |
| [ ] Semantics of type declaration: | |
| - creating a new type (status quo), or only a new type name? | |
| - also: declaration type T S; strips methods of S. why/why not? | |
| Decisions in need of integration into the doc: | |
| [ ] pair assignment is required to get map, and receive ok. | |
| [ ] len() returns an int, new(array_type, n) n must be an int | |
| Todo's: | |
| [ ] document illegality of package-external tuple assignments to structs | |
| w/ private fields: P.T(1, 2) illegal since same as P.T(a: 1, b: 2) for | |
| a T struct { a b int }. | |
| [ ] clarification on interface types, rules | |
| [ ] clarify tuples | |
| [ ] need to talk about precise int/floats clearly | |
| [ ] iant suggests to use abstract/precise int for len(), cap() - good idea | |
| (issue: what happens in len() + const - what is the type?) | |
| [ ] fix "else" part of if statement | |
| [ ] cleanup: 6g allows: interface { f F } where F is a function type. | |
| fine, but then we should also allow: func f F {}, where F is a function type. | |
| [ ] decide if and what to write about evaluation order of tuple assignments | |
| Wish list: | |
| [ ] enum facility (enum symbols that are not mixable with ints) or some other | |
| mechanism to obtain type-safety which we don't have with int-only tags | |
| [ ] Gri: built-in assert() - alternatively: allow entire expressions | |
| as statements so we can write: some_condition || panic(); (along these lines) | |
| [ ] Helper syntax for composite types: allow names/keys/indices for | |
| structs/maps/arrays, remove need for type in elements of composites | |
| Smaller issues: | |
| [ ] do we need channel conversion (channel direction) | |
| Closed: | |
| [x] Russ: If we use x.(T) for all conversions, we could use T() for "construction" | |
| and type literals - would resolve the parsing ambiguity of T{} in if's - | |
| switching to () for literals, conversion discussion still open | |
| [x] Russ: consider re-introducing "func" for function type. Make function literals | |
| behave like slices, etc. Require no &'s to get a function value (solves issue | |
| of func{} vs &func{} vs &func_name). | |
| [x] onreturn/undo statement - now: defer statement | |
| [x] comparison of non-basic types: what do we allow? what do we allow in interfaces | |
| what about maps (require ==, copy and hash) | |
| maybe: no maps with non-basic type keys, and no interface comparison unless | |
| with nil[x] | |
| [x] clarify slice rules | |
| [x] what are the permissible ranges for the indices in slices? The spec | |
| doesn't correspond to the implementation. The spec is wrong when it | |
| comes to the first index i: it should allow (at least) the range 0 <= i <= len(a). | |
| also: document different semantics for strings and arrays (strings cannot be grown). | |
| [x] reopening & and func issue: Seems inconsistent as both &func(){} and func(){} are | |
| permitted. Suggestion: func literals are pointers. We need to use & for all other | |
| functions. This would be in consistency with the declaration of function pointer | |
| variables and the use of '&' to convert methods into function pointers. | |
| - covered by other entry | |
| [x] composite types should uniformly create an instance instead of a pointer - fixed | |
| [x] like to have assert() in the language, w/ option to disable code gen for it | |
| - added to wish list | |
| [x] convert should not be used for composite literals anymore, | |
| in fact, convert() should go away - made a todo | |
| [x] provide composite literal notation to address array indices: []int{ 0: x1, 1: x2, ... } | |
| and struct field names (both seem easy to do). - under "Missing" list | |
| [x] passing a "..." arg to another "..." parameter doesn't wrap the argument again | |
| (so "..." args can be passed down easily) - this is documented | |
| [x] consider syntactic notation for composite literals to make them parsable w/o type information | |
| (require ()'s in control clauses) - use heuristics for now | |
| [x] do we need anything on package vs file names? - current package scheme workable for now | |
| [x] what is the meaning of typeof() - we don't have it | |
| [x] old-style export decls (still needed, but ideally should go away) | |
| [x] packages of multiple files - we have a working approach | |
| [x] partial export of structs, methods | |
| [x] new as it is now is weird - need to go back to previous semantics and introduce | |
| literals for slices, maps, channels - done | |
| [x] determine if really necessary to disallow array assignment - allow array assignment | |
| [x] semantics of statements - we just need to fill in the language, the semantics is mostly clear | |
| [x] range statement: to be defined more reasonably | |
| [x] need to be specific on (unsigned) integer operations: one must be able | |
| to rely on wrap-around on overflow | |
| [x] global var decls: "var a, b, c int = 0, 0, 0" is ok, but "var a, b, c = 0, 0, 0" is not | |
| (seems inconsistent with "var a = 0", and ":=" notation) | |
| [x] const decls: "const a, b = 1, 2" is not allowed - why not? Should be symmetric to vars. | |
| [x] new(arraytype, n1, n2): spec only talks about length, not capacity | |
| (should only use new(arraytype, n) - this will allow later | |
| extension to multi-dim arrays w/o breaking the language) - documented | |
| [x] should we have a shorter list of alias types? (byte, int, uint, float) - done | |
| [x] reflection support | |
| [x] syntax for var args | |
| [x] Do composite literals create a new literal each time (gri thinks yes) (Russ is putting in a change | |
| to this effect, essentially) | |
| [x] comparison operators: can we compare interfaces? | |
| [x] can we add methods to types defined in another package? (probably not) | |
| [x] optional semicolons: too complicated and unclear | |
| [x] anonymous types are written using a type name, which can be a qualified identifier. | |
| this might be a problem when referring to such a field using the type name. | |
| [x] nil and interfaces - can we test for nil, what does it mean, etc. | |
| [x] talk about underflow/overflow of 2's complement numbers (defined vs not defined). | |
| [x] change wording on array composite literals: the types are always fixed arrays | |
| for array composites | |
| [x] meaning of nil | |
| [x] remove "any" | |
| [x] methods for all types | |
| [x] should binary <- be at lowest precedence level? when is a send/receive non-blocking? (NO - 9/19/08) | |
| [x] func literal like a composite type - should probably require the '&' to get address (NO) | |
| [x] & needed to get a function pointer from a function? (NO - there is the "func" keyword - 9/19/08) | |
| [x] Conversions: | |
| - current situation is messy | |
| - 2 (3?) different notations for the same thing | |
| - unclear when a type assertion is needed | |
| - unclear where conversions can be applied | |
| - for type T int; can we say T(3.0) ? | |
| [x] need for type switch? (or use type assertion with ok in tuple assignment?) | |
| [x] Is . import implemented / do we still need it? | |
| [x] Do we allow empty statements? If so, do we allow empty statements after a label? | |
| and if so, does a label followed by an empty statement (a semicolon) still denote | |
| a for loop that is following, and can break L be used inside it? | |
| [x] there is some funniness regarding ';' and empty statements and label decls | |
| [x] cleanup convert() vs T() vs x.(T) - convert() should go away? | |
| [x] decide if and what to write about evaluation order of composite literal | |
| elements (single expressions, (key:value) pairs) | |
| --> | |
| <h2>Introduction</h2> | |
| <p> | |
| This is a reference manual for the Go programming language. For | |
| more information and other documents, see <a | |
| href="/">the Go home page</a>. | |
| </p> | |
| <p> | |
| Go is a general-purpose language designed with systems programming | |
| in mind. It is strongly typed and garbage-collected, and has explicit | |
| support for concurrent programming. Programs are constructed from | |
| <i>packages</i>, whose properties allow efficient management of | |
| dependencies. The existing implementations use a traditional | |
| compile/link model to generate executable binaries. | |
| </p> | |
| <p> | |
| The grammar is compact and regular, allowing for easy analysis by | |
| automatic tools such as integrated development environments. | |
| </p> | |
| <hr/> | |
| <h2>Notation</h2> | |
| <p> | |
| The syntax is specified using Extended Backus-Naur Form (EBNF): | |
| </p> | |
| <pre class="grammar"> | |
| Production = production_name "=" Expression . | |
| Expression = Alternative { "|" Alternative } . | |
| Alternative = Term { Term } . | |
| Term = production_name | token [ "..." token ] | Group | Option | Repetition . | |
| Group = "(" Expression ")" . | |
| Option = "[" Expression "]" . | |
| Repetition = "{" Expression "}" . | |
| </pre> | |
| <p> | |
| Productions are expressions constructed from terms and the following | |
| operators, in increasing precedence: | |
| </p> | |
| <pre class="grammar"> | |
| | alternation | |
| () grouping | |
| [] option (0 or 1 times) | |
| {} repetition (0 to n times) | |
| </pre> | |
| <p> | |
| Lower-case production names are used to identify lexical tokens. | |
| Non-terminals are in CamelCase. Lexical symbols are enclosed in | |
| double quotes <code>""</code> (the double quote symbol is written as | |
| <code>'"'</code>). | |
| </p> | |
| <p> | |
| The form <code>"a ... b"</code> represents the set of characters from | |
| <code>a</code> through <code>b</code> as alternatives. | |
| </p> | |
| <hr/> | |
| <h2>Source code representation</h2> | |
| <p> | |
| Source code is Unicode text encoded in UTF-8. The text is not | |
| canonicalized, so a single accented code point is distinct from the | |
| same character constructed from combining an accent and a letter; | |
| those are treated as two code points. For simplicity, this document | |
| will use the term <i>character</i> to refer to a Unicode code point. | |
| </p> | |
| <p> | |
| Each code point is distinct; for instance, upper and lower case letters | |
| are different characters. | |
| </p> | |
| <h3>Characters</h3> | |
| <p> | |
| The following terms are used to denote specific Unicode character classes: | |
| </p> | |
| <ul> | |
| <li>unicode_char an arbitrary Unicode code point</li> | |
| <li>unicode_letter a Unicode code point classified as "Letter"</li> | |
| <li>capital_letter a Unicode code point classified as "Letter, uppercase"</li> | |
| <li>unicode_digit a Unicode code point classified as "Digit"</li> | |
| </ul> | |
| (The Unicode Standard, Section 4.5 General Category - Normative.) | |
| <h3>Letters and digits</h3> | |
| <p> | |
| The underscore character <code>_</code> (U+005F) is considered a letter. | |
| </> | |
| <pre class="grammar"> | |
| letter = unicode_letter | "_" . | |
| decimal_digit = "0" ... "9" . | |
| octal_digit = "0" ... "7" . | |
| hex_digit = "0" ... "9" | "A" ... "F" | "a" ... "f" . | |
| </pre> | |
| <hr/> | |
| <h2>Lexical elements</h2> | |
| <h3>Comments</h3> | |
| <p> | |
| There are two forms of comments. The first starts at the character | |
| sequence <code>//</code> and continues through the next newline. The | |
| second starts at the character sequence <code>/*</code> and continues | |
| through the character sequence <code>*/</code>. Comments do not nest. | |
| </p> | |
| <h3>Tokens</h3> | |
| <p> | |
| Tokens form the vocabulary of the Go language. | |
| There are four classes: identifiers, keywords, operators | |
| and delimiters, and literals. <i>White space</i>, formed from | |
| blanks, tabs, and newlines, is ignored except as it separates tokens | |
| that would otherwise combine into a single token. Comments | |
| behave as white space. While breaking the input into tokens, | |
| the next token is the longest sequence of characters that form a | |
| valid token. | |
| </p> | |
| <h3>Identifiers</h3> | |
| <p> | |
| Identifiers name program entities such as variables and types. | |
| An identifier is a sequence of one or more letters and digits. | |
| The first character in an identifier must be a letter. | |
| </p> | |
| <pre class="grammar"> | |
| identifier = letter { letter | unicode_digit } . | |
| </pre> | |
| <pre> | |
| a | |
| _x9 | |
| ThisVariableIsExported | |
| αβ | |
| </pre> | |
| Some identifiers are predeclared (§Predeclared identifiers). | |
| <h3>Keywords</h3> | |
| <p> | |
| The following keywords are reserved and may not be used as identifiers. | |
| </p> | |
| <pre class="grammar"> | |
| break default func interface select | |
| case defer go map struct | |
| chan else goto package switch | |
| const fallthrough if range type | |
| continue for import return var | |
| </pre> | |
| <h3>Operators and Delimiters</h3> | |
| <p> | |
| The following character sequences represent operators, delimiters, and other special tokens: | |
| </p> | |
| <pre class="grammar"> | |
| + & += &= && == != ( ) | |
| - | -= |= || < <= [ ] | |
| * ^ *= ^= <- > >= { } | |
| / << /= <<= ++ = := , ; | |
| % >> %= >>= -- ! ... . : | |
| &^ &^= | |
| </pre> | |
| <h3>Integer literals</h3> | |
| <p> | |
| An integer literal is a sequence of one or more digits in the | |
| corresponding base, which may be 8, 10, or 16. An optional prefix | |
| sets a non-decimal base: <code>0</code> for octal, <code>0x</code> or | |
| <code>0X</code> for hexadecimal. In hexadecimal literals, letters | |
| <code>a-f</code> and <code>A-F</code> represent values 10 through 15. | |
| </p> | |
| <pre class="grammar"> | |
| int_lit = decimal_lit | octal_lit | hex_lit . | |
| decimal_lit = ( "1" ... "9" ) { decimal_digit } . | |
| octal_lit = "0" { octal_digit } . | |
| hex_lit = "0" ( "x" | "X" ) hex_digit { hex_digit } . | |
| </pre> | |
| <pre> | |
| 42 | |
| 0600 | |
| 0xBadFace | |
| 170141183460469231731687303715884105727 | |
| </pre> | |
| <h3>Floating-point literals</h3> | |
| <p> | |
| A floating-point literal is a decimal representation of a floating-point | |
| number. It has an integer part, a decimal point, a fractional part, | |
| and an exponent part. The integer and fractional part comprise | |
| decimal digits; the exponent part is an <code>e</code> or <code>E</code> | |
| followed by an optionally signed decimal exponent. One of the | |
| integer part or the fractional part may be elided; one of the decimal | |
| point or the exponent may be elided. | |
| </p> | |
| <pre class="grammar"> | |
| float_lit = decimals "." [ decimals ] [ exponent ] | | |
| decimals exponent | | |
| "." decimals [ exponent ] . | |
| decimals = decimal_digit { decimal_digit } . | |
| exponent = ( "e" | "E" ) [ "+" | "-" ] decimals . | |
| </pre> | |
| <pre> | |
| 0. | |
| 2.71828 | |
| 1.e+0 | |
| 6.67428e-11 | |
| 1E6 | |
| .25 | |
| .12345E+5 | |
| </pre> | |
| <h3>Ideal numbers</h3> | |
| <p> | |
| Integer literals represent values of arbitrary precision, or <i>ideal | |
| integers</i>. Similarly, floating-point literals represent values | |
| of arbitrary precision, or <i>ideal floats</i>. These <i>ideal | |
| numbers</i> have no size or type and cannot overflow. However, | |
| when (used in an expression) assigned to a variable or typed constant, | |
| the destination must be able to represent the assigned value. | |
| </p> | |
| <p> | |
| Implementation restriction: A compiler may implement ideal numbers | |
| by choosing an internal representation with at least twice the precision | |
| of any machine type. | |
| </p> | |
| <h3>Character literals</h3> | |
| <p> | |
| A character literal represents an integer value, typically a | |
| Unicode code point, as one or more characters enclosed in single | |
| quotes. Within the quotes, any character may appear except single | |
| quote and newline. A single quoted character represents itself, | |
| while multi-character sequences beginning with a backslash encode | |
| values in various formats. | |
| </p> | |
| <p> | |
| The simplest form represents the single character within the quotes; | |
| since Go source text is Unicode characters encoded in UTF-8, multiple | |
| UTF-8-encoded bytes may represent a single integer value. For | |
| instance, the literal <code>'a'</code> holds a single byte representing | |
| a literal <code>a</code>, Unicode U+0061, value <code>0x61</code>, while | |
| <code>'ä'</code> holds two bytes (<code>0xc3</code> <code>0xa4</code>) representing | |
| a literal <code>a</code>-dieresis, U+00E4, value <code>0xe4</code>. | |
| </p> | |
| <p> | |
| Several backslash escapes allow arbitrary values to be represented | |
| as ASCII text. There are four ways to represent the integer value | |
| as a numeric constant: <code>\x</code> followed by exactly two hexadecimal | |
| digits; <code>\u</code> followed by exactly four hexadecimal digits; | |
| <code>\U</code> followed by exactly eight hexadecimal digits, and a | |
| plain backslash <code>\</code> followed by exactly three octal digits. | |
| In each case the value of the literal is the value represented by | |
| the digits in the corresponding base. | |
| </p> | |
| <p> | |
| Although these representations all result in an integer, they have | |
| different valid ranges. Octal escapes must represent a value between | |
| 0 and 255 inclusive. (Hexadecimal escapes satisfy this condition | |
| by construction). The `Unicode' escapes <code>\u</code> and <code>\U</code> | |
| represent Unicode code points so within them some values are illegal, | |
| in particular those above <code>0x10FFFF</code> and surrogate halves. | |
| </p> | |
| <p> | |
| After a backslash, certain single-character escapes represent special values: | |
| </p> | |
| <pre class="grammar"> | |
| \a U+0007 alert or bell | |
| \b U+0008 backspace | |
| \f U+000C form feed | |
| \n U+000A line feed or newline | |
| \r U+000D carriage return | |
| \t U+0009 horizontal tab | |
| \v U+000b vertical tab | |
| \\ U+005c backslash | |
| \' U+0027 single quote (valid escape only within character literals) | |
| \" U+0022 double quote (valid escape only within string literals) | |
| </pre> | |
| <p> | |
| All other sequences are illegal inside character literals. | |
| </p> | |
| <pre class="grammar"> | |
| char_lit = "'" ( unicode_value | byte_value ) "'" . | |
| unicode_value = unicode_char | little_u_value | big_u_value | escaped_char . | |
| byte_value = octal_byte_value | hex_byte_value . | |
| octal_byte_value = "\" octal_digit octal_digit octal_digit . | |
| hex_byte_value = "\" "x" hex_digit hex_digit . | |
| little_u_value = "\" "u" hex_digit hex_digit hex_digit hex_digit . | |
| big_u_value = "\" "U" hex_digit hex_digit hex_digit hex_digit | |
| hex_digit hex_digit hex_digit hex_digit . | |
| escaped_char = "\" ( "a" | "b" | "f" | "n" | "r" | "t" | "v" | "\" | "'" | """ ) . | |
| </pre> | |
| <pre> | |
| 'a' | |
| 'ä' | |
| '本' | |
| '\t' | |
| '\000' | |
| '\007' | |
| '\377' | |
| '\x07' | |
| '\xff' | |
| '\u12e4' | |
| '\U00101234' | |
| </pre> | |
| <p> | |
| The value of a character literal is an ideal integer, just as with | |
| integer literals. | |
| </p> | |
| <h3>String literals</h3> | |
| <p> | |
| String literals represent constant values of type <code>string</code>. | |
| There are two forms: raw string literals and interpreted string | |
| literals. | |
| </p> | |
| <p> | |
| Raw string literals are character sequences between back quotes | |
| <code>``</code>. Within the quotes, any character is legal except | |
| newline and back quote. The value of a raw string literal is the | |
| string composed of the uninterpreted bytes between the quotes; | |
| in particular, backslashes have no special meaning. | |
| </p> | |
| <p> | |
| Interpreted string literals are character sequences between double | |
| quotes <code>""</code>. The text between the quotes forms the | |
| value of the literal, with backslash escapes interpreted as they | |
| are in character literals (except that <code>\'</code> is illegal and | |
| <code>\"</code> is legal). The three-digit octal (<code>\000</code>) | |
| and two-digit hexadecimal (<code>\x00</code>) escapes represent individual | |
| <i>bytes</i> of the resulting string; all other escapes represent | |
| the (possibly multi-byte) UTF-8 encoding of individual <i>characters</i>. | |
| Thus inside a string literal <code>\377</code> and <code>\xFF</code> represent | |
| a single byte of value <code>0xFF</code>=255, while <code>ÿ</code>, | |
| <code>\u00FF</code>, <code>\U000000FF</code> and <code>\xc3\xbf</code> represent | |
| the two bytes <code>0xc3 0xbf</code> of the UTF-8 encoding of character | |
| U+00FF. | |
| </p> | |
| <pre class="grammar"> | |
| string_lit = raw_string_lit | interpreted_string_lit . | |
| raw_string_lit = "`" { unicode_char } "`" . | |
| interpreted_string_lit = """ { unicode_value | byte_value } """ . | |
| </pre> | |
| <pre> | |
| `abc` | |
| `\n` | |
| "hello, world\n" | |
| "\n" | |
| "" | |
| "Hello, world!\n" | |
| "日本語" | |
| "\u65e5本\U00008a9e" | |
| "\xff\u00FF" | |
| </pre> | |
| <p> | |
| These examples all represent the same string: | |
| </p> | |
| <pre> | |
| "日本語" // UTF-8 input text | |
| `日本語` // UTF-8 input text as a raw literal | |
| "\u65e5\u672c\u8a9e" // The explicit Unicode code points | |
| "\U000065e5\U0000672c\U00008a9e" // The explicit Unicode code points | |
| "\xe6\x97\xa5\xe6\x9c\xac\xe8\xaa\x9e" // The explicit UTF-8 bytes | |
| </pre> | |
| <p> | |
| If the source code represents a character as two code points, such as | |
| a combining form involving an accent and a letter, the result will be | |
| an error if placed in a character literal (it is not a single code | |
| point), and will appear as two code points if placed in a string | |
| literal. | |
| </p> | |
| <hr/> | |
| <h2>Types</h2> | |
| <p> | |
| A type determines the set of values and operations specific to values of that type. | |
| A type may be specified by a (possibly qualified (§Qualified identifiers)) | |
| type name (§Type declarations) or a <i>type literal</i>, | |
| which composes a new type in terms of previously declared types. | |
| </p> | |
| <pre class="grammar"> | |
| Type = TypeName | TypeLit | "(" Type ")" . | |
| TypeName = QualifiedIdent. | |
| TypeLit = ArrayType | StructType | PointerType | FunctionType | InterfaceType | | |
| SliceType | MapType | ChannelType . | |
| </pre> | |
| <p> | |
| <i>Basic types</i> such as <code>int</code> are predeclared (§Predeclared identifiers). | |
| Other types may be constructed from these, recursively, | |
| including arrays, structs, pointers, functions, interfaces, slices, maps, and | |
| channels. | |
| </p> | |
| <p> | |
| At any point in the source code, a type may be <i>complete</i> or | |
| <i>incomplete</i>. An incomplete type is one whose size is not | |
| yet known, such as a struct whose fields are not yet fully | |
| defined or a forward declared type (§Forward declarations). | |
| Most types are always complete; for instance, a pointer | |
| type is always complete even if it points to an incomplete type | |
| because the size of the pointer itself is always known. | |
| (TODO: Need to figure out how forward declarations of | |
| interface fit in here.) | |
| </p> | |
| <p> | |
| The <i>interface</i> of a type is the set of methods bound to it | |
| (§Method declarations); for pointer types, it is the interface | |
| of the pointer base type (§Pointer types). All types have an interface; | |
| if they have no methods, it is the <i>empty interface</i>. | |
| </p> | |
| <p> | |
| The <i>static type</i> (or just <i>type</i>) of a variable is the | |
| type defined by its declaration. Variables of interface type | |
| (§Interface types) also have a distinct <i>dynamic type</i>, which | |
| is the actual type of the value stored in the variable at run-time. | |
| The dynamic type may vary during execution but is always compatible | |
| with the static type of the interface variable. For non-interfaces | |
| types, the dynamic type is always the static type. | |
| </p> | |
| <h3>Basic types</h3> | |
| <p> | |
| Basic types include traditional numeric types, booleans, and strings. All are predeclared. | |
| </p> | |
| <h3>Numeric types</h3> | |
| <p> | |
| The architecture-independent numeric types are: | |
| </p> | |
| <pre class="grammar"> | |
| uint8 the set of all unsigned 8-bit integers (0 to 255) | |
| uint16 the set of all unsigned 16-bit integers (0 to 65535) | |
| uint32 the set of all unsigned 32-bit integers (0 to 4294967295) | |
| uint64 the set of all unsigned 64-bit integers (0 to 18446744073709551615) | |
| int8 the set of all signed 8-bit integers (-128 to 127) | |
| int16 the set of all signed 16-bit integers (-32768 to 32767) | |
| int32 the set of all signed 32-bit integers (-2147483648 to 2147483647) | |
| int64 the set of all signed 64-bit integers (-9223372036854775808 to 9223372036854775807) | |
| float32 the set of all valid IEEE-754 32-bit floating point numbers | |
| float64 the set of all valid IEEE-754 64-bit floating point numbers | |
| byte familiar alias for uint8 | |
| </pre> | |
| <p> | |
| Integer types are represented in the usual binary format; the value of | |
| an n-bit integer is n bits wide. A negative signed integer is represented | |
| as the two's complement of its absolute value. | |
| </p> | |
| <p> | |
| There is also a set of architecture-independent basic numeric types | |
| whose size depends on the architecture: | |
| </p> | |
| <pre class="grammar"> | |
| uint at least 32 bits, at most the size of the largest uint type | |
| int at least 32 bits, at most the size of the largest int type | |
| float at least 32 bits, at most the size of the largest float type | |
| uintptr smallest uint type large enough to store the uninterpreted | |
| bits of a pointer value | |
| </pre> | |
| <p> | |
| To avoid portability issues all numeric types are distinct except | |
| <code>byte</code>, which is an alias for <code>uint8</code>. | |
| Conversions | |
| are required when different numeric types are mixed in an expression | |
| or assignment. For instance, <code>int32</code> and <code>int</code> | |
| are not the same type even though they may have the same size on a | |
| particular architecture. | |
| <h3>Booleans</h3> | |
| The type <code>bool</code> comprises the Boolean truth values | |
| represented by the predeclared constants <code>true</code> | |
| and <code>false</code>. | |
| <h3>Strings</h3> | |
| <p> | |
| The <code>string</code> type represents the set of textual string values. | |
| Strings behave like arrays of bytes but are immutable: once created, | |
| it is impossible to change the contents of a string. | |
| <p> | |
| The elements of strings have type <code>byte</code> and may be | |
| accessed using the usual indexing operations (§Indexes). It is | |
| illegal to take the address of such an element, that is, even if | |
| <code>s[i]</code> is the <code>i</code><sup>th</sup> byte of a | |
| string, <code>&s[i]</code> is invalid. The length of a string | |
| can be computed by the function <code>len(s1)</code>. | |
| </p> | |
| <p> | |
| A sequence of string literals is concatenated into a single string. | |
| </p> | |
| <pre class="grammar"> | |
| StringLit = string_lit { string_lit } . | |
| </pre> | |
| <pre> | |
| "Alea iacta est." | |
| "Alea " /* The die */ `iacta est` /* is cast */ "." | |
| </pre> | |
| <h3>Array types</h3> | |
| <p> | |
| An array is a numbered sequence of elements of a single | |
| type, called the element type, which must be complete | |
| (§Types). The number of elements is called the length and is never | |
| negative. | |
| </p> | |
| <pre class="grammar"> | |
| ArrayType = "[" ArrayLength "]" ElementType . | |
| ArrayLength = Expression . | |
| ElementType = CompleteType . | |
| </pre> | |
| <p> | |
| The length is part of the array's type and must must be a constant | |
| expression (§Constant expressions) that evaluates to a non-negative | |
| integer value. The length of array <code>a</code> can be discovered | |
| using the built-in function <code>len(a)</code>, which is a | |
| compile-time constant. The elements can be indexed by integer | |
| indices 0 through the <code>len(a)-1</code> (§Indexes). | |
| </p> | |
| <pre> | |
| [32]byte | |
| [2*N] struct { x, y int32 } | |
| [1000]*float64 | |
| </pre> | |
| <h3>Slice types</h3> | |
| <p> | |
| A slice is a reference to a contiguous segment of an array and | |
| contains a numbered sequence of elements from that array. A slice | |
| type denotes the set of all slices of arrays of its element type. | |
| A slice value may be <code>nil</code>. | |
| </p> | |
| <pre class="grammar"> | |
| SliceType = "[" "]" ElementType . | |
| </pre> | |
| <p> | |
| Like arrays, slices are indexable and have a length. The length of a | |
| slice <code>s</code> can be discovered by the built-in function | |
| <code>len(s)</code>; unlike with arrays it may change during | |
| execution. The elements can be addressed by integer indices 0 | |
| through <code>len(s)-1</code> (§Indexes). The slice index of a | |
| given element may be less than the index of the same element in the | |
| underlying array. | |
| </p> | |
| <p> | |
| A slice, once initialized, is always associated with an underlying | |
| array that holds its elements. A slice therfore shares storage | |
| with its array and with other slices of the same array; by contrast, | |
| distinct arrays always represent distinct storage. | |
| </p> | |
| <p> | |
| The array underlying a slice may extend past the end of the slice. | |
| The <i>capacity</i> is a measure of that extent: it is the sum of | |
| the length of the slice and the length of the array beyond the slice; | |
| a slice of length up to that capacity can be created by `slicing' a new | |
| one from the original slice (§Slices). | |
| The capacity of a slice <code>a</code> can be discovered using the | |
| built-in function | |
| </p> | |
| <pre> | |
| cap(s) | |
| </pre> | |
| <p> | |
| and the relationship between <code>len()</code> and <code>cap()</code> is: | |
| </p> | |
| <pre> | |
| 0 <= len(a) <= cap(a) | |
| </pre> | |
| <p> | |
| The value of an uninitialized slice is <code>nil</code>. | |
| The length and capacity of a <code>nil</code> slice | |
| are 0. A new, initialized slice value for a given element type <code>T</code> is | |
| made using the built-in function <code>make</code>, which takes a slice type | |
| and parameters specifying the length and optionally the capacity: | |
| </p> | |
| <pre> | |
| make([]T, length) | |
| make([]T, length, capacity) | |
| </pre> | |
| <p> | |
| The <code>make()</code> call allocates a new, hidden array to which the returned | |
| slice value refers. That is, calling <code>make</code> | |
| </p> | |
| <pre> | |
| make([]T, length, capacity) | |
| </pre> | |
| <p> | |
| produces the same slice as allocating an array and slicing it, so these two examples | |
| result in the same slice: | |
| </p> | |
| <pre> | |
| make([]int, 50, 100) | |
| new([100]int)[0:50] | |
| </pre> | |
| <h3>Struct types</h3> | |
| <p> | |
| A struct is a sequence of named | |
| elements, called fields, with various types. A struct type declares | |
| an identifier and type for each field. Within a struct, field identifiers | |
| must be unique and field types must be complete (§Types). | |
| </p> | |
| <pre class="grammar"> | |
| StructType = "struct" "{" [ FieldDeclList ] "}" . | |
| FieldDeclList = FieldDecl { ";" FieldDecl } [ ";" ] . | |
| FieldDecl = (IdentifierList CompleteType | [ "*" ] TypeName) [ Tag ] . | |
| Tag = StringLit . | |
| </pre> | |
| <pre> | |
| // An empty struct. | |
| struct {} | |
| // A struct with 5 fields. | |
| struct { | |
| x, y int; | |
| u float; | |
| A *[]int; | |
| F func(); | |
| } | |
| </pre> | |
| <p> | |
| A field declared with a type but no field identifier is an <i>anonymous field</i>. | |
| Such a field type must be specified as | |
| a type name <code>T</code> or as a pointer to a type name <code>*T</code>, | |
| and <code>T</code> itself, may not be | |
| a pointer or interface type. The unqualified type name acts as the field identifier. | |
| </p> | |
| <pre> | |
| // A struct with four anonymous fields of type T1, *T2, P.T3 and *P.T4 | |
| struct { | |
| T1; // the field name is T1 | |
| *T2; // the field name is T2 | |
| P.T3; // the field name is T3 | |
| *P.T4; // the field name is T4 | |
| x, y int; | |
| } | |
| </pre> | |
| <p> | |
| The unqualified type name of an anonymous field must not conflict with the | |
| field identifier (or unqualified type name for an anonymous field) of any | |
| other field within the struct. The following declaration is illegal: | |
| </p> | |
| <pre> | |
| struct { | |
| T; // conflicts with anonymous field *T and *P.T | |
| *T; // conflicts with anonymous field T and *P.T | |
| *P.T; // conflicts with anonymous field T and *T | |
| } | |
| </pre> | |
| <p> | |
| Fields and methods (§Method declarations) of an anonymous field are | |
| promoted to be ordinary fields and methods of the struct (§Selectors). | |
| </p> | |
| <p> | |
| A field declaration may be followed by an optional string literal <i>tag</i>, which | |
| becomes an attribute for all the identifiers in the corresponding | |
| field declaration. The tags are made | |
| visible through a reflection library (TODO: reference?) | |
| but are otherwise ignored. | |
| </p> | |
| <pre> | |
| // A struct corresponding to the EventIdMessage protocol buffer. | |
| // The tag strings define the protocol buffer field numbers. | |
| struct { | |
| time_usec uint64 "field 1"; | |
| server_ip uint32 "field 2"; | |
| process_id uint32 "field 3"; | |
| } | |
| </pre> | |
| <h3>Pointer types</h3> | |
| <p> | |
| A pointer type denotes the set of all pointers to variables of a given | |
| type, called the <i>base type</i> of the pointer. | |
| A pointer value may be <code>nil</code>. | |
| </p> | |
| <pre class="grammar"> | |
| PointerType = "*" BaseType . | |
| BaseType = Type . | |
| </pre> | |
| <pre> | |
| *int | |
| *map[string] *chan int | |
| </pre> | |
| <h3>Function types</h3> | |
| <p> | |
| A function type denotes the set of all functions with the same parameter | |
| and result types. | |
| A function value may be <code>nil</code>. | |
| </p> | |
| <pre class="grammar"> | |
| FunctionType = "func" Signature . | |
| Signature = Parameters [ Result ] . | |
| Result = Parameters | CompleteType . | |
| Parameters = "(" [ ParameterList ] ")" . | |
| ParameterList = ParameterDecl { "," ParameterDecl } . | |
| ParameterDecl = [ IdentifierList ] ( CompleteType | "..." ) . | |
| </pre> | |
| <p> | |
| Within a list of parameters or results, the names (IdentifierList) | |
| must either all be present or all be absent. If present, each name | |
| stands for one item (parameter or result) of the specified type; if absent, each | |
| type stands for one item of that type. Parameter and result | |
| lists are always parenthesized except that if there is exactly | |
| one unnamed result that is not a function type it may writen as an unparenthesized type. | |
| The types of parameters and results must be complete. | |
| (TODO: is completeness necessary?) | |
| </p> | |
| <p> | |
| For the last parameter only, instead of a type one may write | |
| <code>...</code> to indicate that the function may be invoked with | |
| zero or more additional arguments of any | |
| type. If parameters of such a function are named, the final identifier | |
| list must be a single name, that of the <code>...</code> parameter. | |
| </p> | |
| <pre> | |
| func () | |
| func (x int) | |
| func () int | |
| func (string, float, ...) | |
| func (a, b int, z float) bool | |
| func (a, b int, z float) (bool) | |
| func (a, b int, z float, opt ...) (success bool) | |
| func (int, int, float) (float, *[]int) | |
| func (n int) (func (p* T)) | |
| </pre> | |
| <h3>Interface types</h3> | |
| <p> | |
| An interface type specifies an unordered set of methods. A variable | |
| of interface type can store, dynamically, any value that implements | |
| at least that set of methods. | |
| An interface value may be <code>nil</code>. | |
| </p> | |
| <pre class="grammar"> | |
| InterfaceType = "interface" "{" [ MethodSpecList ] "}" . | |
| MethodSpecList = MethodSpec { ";" MethodSpec } [ ";" ] . | |
| MethodSpec = IdentifierList Signature | InterfaceTypeName . | |
| InterfaceTypeName = TypeName . | |
| </pre> | |
| <pre> | |
| // A simple File interface | |
| interface { | |
| Read, Write (b Buffer) bool; | |
| Close (); | |
| } | |
| </pre> | |
| <p> | |
| Any type (including interface types) whose interface includes, | |
| possibly as a subset, the complete set of methods of an interface <code>I</code> | |
| is said to implement interface <code>I</code>. | |
| For instance, if two types <code>S1</code> and <code>S2</code> | |
| have the methods | |
| </p> | |
| <pre> | |
| func (p T) Read(b Buffer) bool { return ... } | |
| func (p T) Write(b Buffer) bool { return ... } | |
| func (p T) Close() { ... } | |
| </pre> | |
| <p> | |
| (where <code>T</code> stands for either <code>S1</code> or <code>S2</code>) | |
| then the <code>File</code> interface is implemented by both <code>S1</code> and | |
| <code>S2</code>, regardless of what other methods | |
| <code>S1</code> and <code>S2</code> may have or share. | |
| </p> | |
| <p> | |
| A type implements any interface comprising any subset of its methods | |
| and may therefore implement several distinct interfaces. For | |
| instance, all types implement the <i>empty interface</i>: | |
| </p> | |
| <pre> | |
| interface { } | |
| </pre> | |
| <p> | |
| Similarly, consider this interface specification, | |
| which appears within a type declaration (§Type declarations) | |
| to define an interface called <code>Lock</code>: | |
| </p> | |
| <pre> | |
| type Lock interface { | |
| Lock, Unlock (); | |
| } | |
| </pre> | |
| <p> | |
| If <code>S1</code> and <code>S2</code> also implement | |
| </p> | |
| <pre> | |
| func (p T) Lock() { ... } | |
| func (p T) Unlock() { ... } | |
| </pre> | |
| <p> | |
| they implement the <code>Lock</code> interface as well | |
| as the <code>File</code> interface. | |
| </p> | |
| <p> | |
| An interface may contain an interface type name <code>T</code> | |
| in place of a method specification. | |
| In this notation, <code>T</code> must denote a different, complete interface type | |
| and the effect is equivalent to enumerating the methods of <code>T</code> explicitly | |
| in the interface. | |
| </p> | |
| <pre> | |
| type ReadWrite interface { | |
| Read, Write (b Buffer) bool; | |
| } | |
| type File interface { | |
| ReadWrite; // same as enumerating the methods in ReadWrite | |
| Lock; // same as enumerating the methods in Lock | |
| Close(); | |
| } | |
| </pre> | |
| <h3>Map types</h3> | |
| <p> | |
| A map is an unordered group of elements of one type, called the | |
| value type, indexed by a set of unique <i>keys</i> of another type, | |
| called the key type. Both key and value types must be complete. | |
| (§Types). | |
| (TODO: is completeness necessary here?) | |
| A map value may be <code>nil</code>. | |
| </p> | |
| <pre class="grammar"> | |
| MapType = "map" "[" KeyType "]" ValueType . | |
| KeyType = CompleteType . | |
| ValueType = CompleteType . | |
| </pre> | |
| <p> | |
| The comparison operators <code>==</code> and <code>!=</code> | |
| (§Comparison operators) must be fully defined for operands of the | |
| key type; thus the key type must be a basic, pointer, interface, | |
| map, or channel type. If the key type is an interface type, these | |
| comparison operators must be defined for the dynamic key values; | |
| failure will cause a run-time error. | |
| </p> | |
| <pre> | |
| map [string] int | |
| map [*T] struct { x, y float } | |
| map [string] interface {} | |
| </pre> | |
| <p> | |
| The number of elements is called the length and is never negative. | |
| The length of a map <code>m</code> can be discovered using the | |
| built-in function <code>len(m)</code> and may change during execution. | |
| The value of an uninitialized map is <code>nil</code>. | |
| </p> | |
| <p> | |
| Upon creation, a map is empty. Values may be added and removed | |
| during execution using special forms of assignment (§Assignments). | |
| A new, empty map value is made using the built-in | |
| function <code>make</code>, which takes the map type and an optional | |
| capacity hint as arguments: | |
| </p> | |
| <pre> | |
| make(map[string] int) | |
| make(map[string] int, 100) | |
| </pre> | |
| <p> | |
| The initial capacity does not bound its size: | |
| maps grow to accommodate the number of items | |
| stored in them. | |
| </p> | |
| <h3>Channel types</h3> | |
| <p> | |
| A channel provides a mechanism for two concurrently executing functions | |
| to synchronize execution and communicate by passing a value of a | |
| specified element type. The element type must be complete (§Types). | |
| (TODO: is completeness necessary here?) | |
| A channel value may be <code>nil</code>. | |
| </p> | |
| <pre class="grammar"> | |
| ChannelType = Channel | SendChannel | RecvChannel . | |
| Channel = "chan" ValueType . | |
| SendChannel = "chan" "<-" ValueType . | |
| RecvChannel = "<-" "chan" ValueType . | |
| </pre> | |
| <p> | |
| Upon creation, a channel can be used both to send and to receive values. | |
| By conversion or assignment, a channel may be constrained only to send or | |
| to receive. This constraint is called a channel's <i>direction</i>; either | |
| <i>send</i>, <i>receive</i>, or <i>bi-directional</i> (unconstrained). | |
| </p> | |
| <pre> | |
| chan T // can be used to send and receive values of type T | |
| chan <- float // can only be used to send floats | |
| <-chan int // can only be used to receive ints | |
| </pre> | |
| <p> | |
| The value of an uninitialized channel is <code>nil</code>. A new, initialized channel | |
| value is made using the built-in function <code>make</code>, | |
| which takes the channel type and an optional capacity as arguments: | |
| </p> | |
| <pre> | |
| make(chan int, 100) | |
| </pre> | |
| <p> | |
| The capacity, in number of elements, sets the size of the buffer in the channel. If the | |
| capacity is greater than zero, the channel is asynchronous and, provided the | |
| buffer is not full, sends can succeed without blocking. If the capacity is zero | |
| or absent, the communication succeeds only when both a sender and receiver are ready. | |
| </p> | |
| <p> | |
| For a channel <code>c</code>, the predefined function <code>close(c)</code> | |
| marks the channel as unable to accept more | |
| values through a send operation. After any previously | |
| sent values have been received, receives will return | |
| the zero value for the channel's type. After at least one such zero value has been | |
| received, <code>closed(c)</code> returns true. | |
| </p> | |
| <h2>General properties of types and values</h2> | |
| <p> | |
| Types may be <i>different</i>, <i>structurally equal</i> (or just <i>equal</i>), | |
| or <i>identical</i>. | |
| Go is <i>type safe</i>: different types cannot be mixed | |
| in binary operations and values cannot be assigned to variables of different | |
| types. Values can be assigned to variables of equal type. | |
| </p> | |
| <h3>Type equality and identity </h3> | |
| <p> | |
| Two type names denote equal types if the types in the corresponding declarations | |
| are equal (§Declarations and Scope). | |
| Two type literals specify equal types if they have the same | |
| literal structure and corresponding components have equal types. | |
| In detail: | |
| </p> | |
| <ul> | |
| <li>Two pointer types are equal if they have equal base types.</li> | |
| <li>Two array types are equal if they have equal element types and | |
| the same array length.</li> | |
| <li>Two struct types are equal if they have the same sequence of fields, | |
| with the same names and equal types. Two anonymous fields are | |
| considered to have the same name.</li> | |
| <li>Two function types are equal if they have the same number of parameters | |
| and result values and if corresponding parameter and result types are | |
| the same. All "..." parameters have equal type. | |
| Parameter and result names are not required to match.</li> | |
| <li>Two slice types are equal if they have equal element types.</li> | |
| <li>Two channel types are equal if they have equal value types and | |
| the same direction.</li> | |
| <li>Two map types are equal if they have equal key and value types.</li> | |
| <li>Two interface types are equal if they have the same set of methods | |
| with the same names and equal function types. The order | |
| of the methods is irrelevant.</li> | |
| </ul> | |
| <p> | |
| Type identity is more stringent than type equality. | |
| It requires for type names | |
| that they originate in the same type declaration, while for equality it requires | |
| only that they originate in equal type declarations. | |
| Also, the names of parameters and results must match for function types. | |
| In all other respects, the definition of type identity is the | |
| same as for type equality listed above but with ``identical'' | |
| substitued for ``equal''. | |
| </p> | |
| <p> | |
| By definition, identical types are also equal types. | |
| Two types are different if they are not equal. | |
| </p> | |
| <p> | |
| Given the declarations | |
| </p> | |
| <pre> | |
| type ( | |
| T0 []string; | |
| T1 []string | |
| T2 struct { a, b int }; | |
| T3 struct { a, c int }; | |
| T4 func (int, float) *T0 | |
| T5 func (x int, y float) *[]string | |
| ) | |
| </pre> | |
| <p> | |
| these types are equal: | |
| </p> | |
| <pre> | |
| T0 and T0 | |
| T0 and T1 | |
| T0 and []string | |
| T4 and T5 | |
| T3 and struct { a int; c int } | |
| </pre> | |
| <p> | |
| <code>T2</code> and <code>T3</code> are not equal because | |
| they have different field names. | |
| </p> | |
| <p> | |
| These types are identical: | |
| </p> | |
| <pre> | |
| T0 and T0 | |
| []int and []int | |
| struct { a, b *T5 } and struct { a, b *T5 } | |
| </pre> | |
| <p> | |
| <code>T0</code> and <code>T1</code> are equal but not | |
| identical because they have distinct declarations. | |
| </p> | |
| <h3>Assignment compatibility</h3> | |
| <p> | |
| Values of any type may always be assigned to variables | |
| of equal static type. Some types and values have conditions under which they may | |
| be assigned to different types: | |
| </p> | |
| <ul> | |
| <li> | |
| The predeclared constant <code>nil</code> can be assigned to any | |
| pointer, function, slice, map, channel, or interface variable. | |
| <li> | |
| Arrays can be assigned to slice variables with equal element type. | |
| When assigning to a slice variable, the array is not copied but a | |
| slice comprising the entire array is created. | |
| </li> | |
| <li> | |
| A value can be assigned to an interface variable if the static | |
| type of the value implements the interface. | |
| </li> | |
| <li> | |
| A value of bidirectional channel type can be assigned to any channel | |
| variable of equal channel value type. | |
| </li> | |
| </ul> | |
| <h3>Comparison compatibility</h3> | |
| <p> | |
| Values of any type may be compared to other values of equal static | |
| type. Values of numeric and string type may be compared using the | |
| full range of comparison operators as described in §Comparison operators; | |
| booleans may be compared only for equality or inequality. | |
| </p> | |
| <p> | |
| Values of composite type may be | |
| compared for equality or inequality using the <code>==</code> and | |
| <code>!=</code> operators, with the following provisos: | |
| </p> | |
| <ul> | |
| <li> | |
| Arrays and structs may not be compared to anything. | |
| </li> | |
| <li> | |
| A slice value may only be compared explicitly against <code>nil</code>. | |
| A slice value is equal to <code>nil</code> if it has been assigned the explicit | |
| value <code>nil</code> or if it is a variable (or array element, | |
| field, etc.) that has not been modified since it was created | |
| uninitialized. | |
| </li> | |
| <li> | |
| Similarly, an interface value is equal to <code>nil</code> if it has | |
| been assigned the explicit value <code>nil</code> or if it is a | |
| variable (or array element, field, etc.) that has not been modified | |
| since it was created uninitialized. | |
| </li> | |
| <li> | |
| For types that can be compared to <code>nil</code>, | |
| two values of the same type are equal if they both equal <code>nil</code>, | |
| unequal if one equals <code>nil</code> and one does not. | |
| </li> | |
| <li> | |
| Pointer values are equal if they point to the same location. | |
| </li> | |
| <li> | |
| Function values are equal if they refer to the same function. | |
| </li> | |
| <li> | |
| Channel and map values are equal if they were created by the same call to <code>make</code> | |
| (§Making slices, maps, and channels). | |
| </li> | |
| <li> | |
| Interface values may be compared if they have the same static type. | |
| They will be equal only if they have the same dynamic type and the underlying values are equal. | |
| </li> | |
| </ul> | |
| <hr/> | |
| <h2>Declarations and Scope</h2> | |
| <p> | |
| A declaration binds an identifier to a language entity such as | |
| a variable or function and specifies properties such as its type. | |
| Every identifier in a program must be declared. | |
| </p> | |
| <pre class="grammar"> | |
| Declaration = ConstDecl | TypeDecl | VarDecl | FunctionDecl | MethodDecl . | |
| </pre> | |
| <p> | |
| The <i>scope</i> of an identifier is the extent of source text within which the | |
| identifier denotes the bound entity. No identifier may be declared twice in a | |
| single scope, but inner blocks can declare a new entity with the same | |
| identifier, in which case the scope created by the outer declaration excludes | |
| that created by the inner. | |
| </p> | |
| <p> | |
| There are levels of scoping in effect before each source file is compiled. | |
| In order from outermost to innermost: | |
| </p> | |
| <ol> | |
| <li>The <i>universe</i> scope contains all predeclared identifiers.</li> | |
| <li>An implicit scope contains only the package name.</li> | |
| <li>The <i>package-level</i> scope surrounds all declarations at the | |
| top level of the file, that is, outside the body of any | |
| function or method. That scope is shared across all | |
| source files within the package (§Packages), allowing | |
| package-level identifiers to be shared between source | |
| files.</li> | |
| </ol> | |
| <p> | |
| The scope of an identifier depends on the entity declared: | |
| </p> | |
| <ol> | |
| <li> The scope of predeclared identifiers is the universe scope.</li> | |
| <li> The scope of an identifier denoting a type, function or package | |
| extends from the point of the identifier in the declaration | |
| to the end of the innermost surrounding block.</li> | |
| <li> The scope of a constant or variable extends textually from | |
| the end of its declaration to the end of the innermost | |
| surrounding block. If the variable is declared in the | |
| <i>init</i> statement of an <code>if</code>, <code>for</code>, | |
| or <code>switch </code> statement, the | |
| innermost surrounding block is the block associated | |
| with that statement.</li> | |
| <li> The scope of a parameter or result is the body of the | |
| corresponding function.</li> | |
| <li> The scope of a field or method is selectors for the | |
| corresponding type containing the field or method (§Selectors).</li> | |
| <li> The scope of a label is a special scope emcompassing | |
| the body of the innermost surrounding function, excluding | |
| nested functions. Labels do not conflict with non-label identifiers.</li> | |
| </ol> | |
| <h3>Predeclared identifiers</h3> | |
| <p> | |
| The following identifiers are implicitly declared in the outermost scope: | |
| </p> | |
| <pre class="grammar"> | |
| Basic types: | |
| bool byte float32 float64 int8 int16 int32 int64 | |
| string uint8 uint16 uint32 uint64 | |
| Architecture-specific convenience types: | |
| float int uint uintptr | |
| Constants: | |
| true false iota nil | |
| Functions: | |
| cap len make new panic panicln print println | |
| Packages: | |
| sys (TODO: does sys endure?) | |
| </pre> | |
| <h3>Exported identifiers</h3> | |
| <p> | |
| By default, identifiers are visible only within the package in which they are declared. | |
| Some identifiers are <i>exported</i> and can be referenced using | |
| <i>qualified identifiers</i> in other packages (§Qualified identifiers). | |
| If an identifier satisfies these two conditions: | |
| </p> | |
| <ol> | |
| <li>the first character of the identifier's name is a Unicode upper case letter; | |
| <li>the identifier is declared at the package level or is a field or method of a type | |
| declared at the top level; | |
| </ol> | |
| <p> | |
| it will be exported automatically. | |
| </p> | |
| <h3>Const declarations</h3> | |
| <p> | |
| A constant declaration binds a list of identifiers (the names of | |
| the constants) to the values of a list of constant expressions | |
| (§Constant expressions). The number of identifiers must be equal | |
| to the number of expressions, and the n<sup>th</sup> identifier on | |
| the left is bound to value of the n<sup>th</sup> expression on the | |
| right. | |
| </p> | |
| <pre class="grammar"> | |
| ConstDecl = "const" ( ConstSpec | "(" [ ConstSpecList ] ")" ) . | |
| ConstSpecList = ConstSpec { ";" ConstSpec } [ ";" ] . | |
| ConstSpec = IdentifierList [ [ CompleteType ] "=" ExpressionList ] . | |
| IdentifierList = identifier { "," identifier } . | |
| ExpressionList = Expression { "," Expression } . | |
| CompleteType = Type . | |
| </pre> | |
| <p> | |
| If the type (CompleteType) is omitted, the constants take the | |
| individual types of the corresponding expressions, which may be | |
| <i>ideal integer</i> or <i>ideal float</i> (§Ideal number). If the type | |
| is present, all constants take the type specified, and the types | |
| of all the expressions must be assignment-compatible | |
| with that type. | |
| </p> | |
| <pre> | |
| const Pi float64 = 3.14159265358979323846 | |
| const E = 2.718281828 | |
| const ( | |
| size int64 = 1024; | |
| eof = -1; | |
| ) | |
| const a, b, c = 3, 4, "foo" // a = 3, b = 4, c = "foo" | |
| const u, v float = 0, 3 // u = 0.0, v = 3.0 | |
| </pre> | |
| <p> | |
| Within a parenthesized <code>const</code> declaration list the | |
| expression list may be omitted from any but the first declaration. | |
| Such an empty list is equivalent to the textual substitution of the | |
| first preceding non-empty expression list, and its type if any. | |
| Omitting the list of expressions is therefore equivalent to | |
| repeating the previous list. The number of identifiers must be equal | |
| to the number of expressions in the previous list. | |
| Together with the <code>iota</code> constant generator | |
| (§Iota) this mechanism permits light-weight declaration of sequential values: | |
| </p> | |
| <pre> | |
| const ( | |
| Sunday = iota; | |
| Monday; | |
| Tuesday; | |
| Wednesday; | |
| Thursday; | |
| Friday; | |
| Partyday; | |
| numberOfDays; // this constant is not exported | |
| ) | |
| </pre> | |
| <h3>Iota</h3> | |
| <p> | |
| Within a constant declaration, the predeclared pseudo-constant | |
| <code>iota</code> represents successive integers. It is reset to 0 | |
| whenever the reserved word <code>const</code> appears in the source | |
| and increments with each semicolon. It can be used to construct a | |
| set of related constants: | |
| </p> | |
| <pre> | |
| const ( // iota is reset to 0 | |
| c0 = iota; // c0 == 0 | |
| c1 = iota; // c1 == 1 | |
| c2 = iota // c2 == 2 | |
| ) | |
| const ( | |
| a = 1 << iota; // a == 1 (iota has been reset) | |
| b = 1 << iota; // b == 2 | |
| c = 1 << iota; // c == 4 | |
| ) | |
| const ( | |
| u = iota * 42; // u == 0 (ideal integer) | |
| v float = iota * 42; // v == 42.0 (float) | |
| w = iota * 42; // w == 84 (ideal integer) | |
| ) | |
| const x = iota; // x == 0 (iota has been reset) | |
| const y = iota; // y == 0 (iota has been reset) | |
| </pre> | |
| <p> | |
| Within an ExpressionList, the value of each <code>iota</code> is the same because | |
| it is only incremented at a semicolon: | |
| </p> | |
| <pre> | |
| const ( | |
| bit0, mask0 = 1 << iota, 1 << iota - 1; // bit0 == 1, mask0 == 0 | |
| bit1, mask1; // bit1 == 2, mask1 == 1 | |
| bit2, mask2; // bit2 == 4, mask2 == 3 | |
| ) | |
| </pre> | |
| <p> | |
| This last example exploits the implicit repetition of the | |
| last non-empty expression list. | |
| </p> | |
| <h3>Type declarations</h3> | |
| <p> | |
| A type declaration binds an identifier, the <i>type name</i>, | |
| to a new type. <font color=red>TODO: what exactly is a "new type"?</font> | |
| </p> | |
| <pre class="grammar"> | |
| TypeDecl = "type" ( TypeSpec | "(" [ TypeSpecList ] ")" ) . | |
| TypeSpecList = TypeSpec { ";" TypeSpec } [ ";" ] . | |
| TypeSpec = identifier ( Type | "struct" | "interface" ) . | |
| </pre> | |
| <pre> | |
| type IntArray [16] int | |
| type ( | |
| Point struct { x, y float }; | |
| Polar Point | |
| ) | |
| type Comparable interface | |
| type TreeNode struct { | |
| left, right *TreeNode; | |
| value *Comparable; | |
| } | |
| type Comparable interface { | |
| cmp(Comparable) int | |
| } | |
| </pre> | |
| <h3>Variable declarations</h3> | |
| <p> | |
| A variable declaration creates a variable, binds an identifier to it and | |
| gives it a type and optionally an initial value. | |
| The type must be complete (§Types). | |
| </p> | |
| <pre class="grammar"> | |
| VarDecl = "var" ( VarSpec | "(" [ VarSpecList ] ")" ) . | |
| VarSpecList = VarSpec { ";" VarSpec } [ ";" ] . | |
| VarSpec = IdentifierList ( CompleteType [ "=" ExpressionList ] | "=" ExpressionList ) . | |
| </pre> | |
| <pre> | |
| var i int | |
| var U, V, W float | |
| var k = 0 | |
| var x, y float = -1.0, -2.0 | |
| var ( | |
| i int; | |
| u, v, s = 2.0, 3.0, "bar" | |
| ) | |
| </pre> | |
| <p> | |
| If there are expressions, their number must be equal | |
| to the number of identifiers, and the n<sup>th</sup> variable | |
| is initialized to the value of the n<sup>th</sup> expression. | |
| Otherwise, each variable is initialized to the <i>zero</i> | |
| of the type (§The zero value). | |
| The expressions can be general expressions; they need not be constants. | |
| </p> | |
| <p> | |
| Either the type or the expression list must be present. If the | |
| type is present, it sets the type of each variable and the expressions | |
| (if any) must be assignment-compatible to that type. If the type | |
| is absent, the variables take the types of the corresponding | |
| expressions. | |
| </p> | |
| <p> | |
| If the type is absent and the corresponding expression is a constant | |
| expression of ideal integer or ideal float type, the type of the | |
| declared variable is <code>int</code> or <code>float</code> | |
| respectively: | |
| </p> | |
| <pre> | |
| var i = 0 // i has type int | |
| var f = 3.1415 // f has type float | |
| </pre> | |
| <h3>Short variable declarations</h3> | |
| A <i>short variable declaration</i> uses the syntax | |
| <pre class="grammar"> | |
| SimpleVarDecl = IdentifierList ":=" ExpressionList . | |
| </pre> | |
| and is shorthand for the declaration syntax | |
| <pre class="grammar"> | |
| "var" IdentifierList = ExpressionList . | |
| </pre> | |
| <pre> | |
| i, j := 0, 10; | |
| f := func() int { return 7; } | |
| ch := make(chan int); | |
| </pre> | |
| <p> | |
| Unlike regular variable declarations, short variable declarations | |
| can be used, by analogy with tuple assignment (§Assignments), to | |
| receive the individual elements of a multi-valued expression such | |
| as a call to a multi-valued function. In this form, the ExpressionList | |
| must be a single such multi-valued expression, the number of | |
| identifiers must equal the number of values, and the declared | |
| variables will be assigned the corresponding values. | |
| </p> | |
| <pre> | |
| r, w := os.Pipe(fd); // os.Pipe() returns two values | |
| </pre> | |
| <p> | |
| Short variable declarations may appear only inside functions. | |
| In some contexts such as the initializers for <code>if</code>, | |
| <code>for</code>, or <code>switch</code> statements, | |
| they can be used to declare local temporary variables (§Statements). | |
| </p> | |
| <h3>Function declarations</h3> | |
| <p> | |
| A function declaration binds an identifier to a function (§Function types). | |
| </p> | |
| <pre class="grammar"> | |
| FunctionDecl = "func" identifier Signature [ Block ] . | |
| </pre> | |
| <pre> | |
| func min(x int, y int) int { | |
| if x < y { | |
| return x; | |
| } | |
| return y; | |
| } | |
| </pre> | |
| <p> | |
| A function must be declared or forward-declared before it can be invoked (§Forward declarations). | |
| Implementation restriction: Functions can only be declared at the package level. | |
| </p> | |
| <h3>Method declarations</h3> | |
| <p> | |
| A method declaration binds an identifier to a method, | |
| which is a function with a <i>receiver</i>. | |
| </p> | |
| <pre class="grammar"> | |
| MethodDecl = "func" Receiver identifier Signature [ Block ] . | |
| Receiver = "(" [ identifier ] [ "*" ] TypeName ")" . | |
| </pre> | |
| <p> | |
| The receiver type must be a type name or a pointer to a type name, | |
| and that name is called the <i>receiver base type</i> or just <i>base type</i>. | |
| The base type must not be a pointer type and must be | |
| declared in the same source file as the method. | |
| The method is said to be <i>bound</i> to the base type | |
| and is visible only within selectors for that type | |
| (§Type declarations, §Selectors). | |
| </p> | |
| <p> | |
| All methods bound to a base type must have the same receiver type, | |
| either all pointers to the base type or all the base type itself. | |
| Given type <code>Point</code>, the declarations | |
| </p> | |
| <pre> | |
| func (p *Point) Length() float { | |
| return Math.sqrt(p.x * p.x + p.y * p.y); | |
| } | |
| func (p *Point) Scale(factor float) { | |
| p.x = p.x * factor; | |
| p.y = p.y * factor; | |
| } | |
| </pre> | |
| <p> | |
| bind the methods <code>Length</code> and <code>Scale</code> | |
| to the base type <code>Point</code>. | |
| </p> | |
| <p> | |
| If the | |
| receiver's value is not referenced inside the the body of the method, | |
| its identifier may be omitted in the declaration. The same applies in | |
| general to parameters of functions and methods. | |
| </p> | |
| <p> | |
| Methods can be declared | |
| only after their base type is declared or forward-declared, and invoked | |
| only after their own declaration or forward-declaration (§Forward declarations). | |
| Implementation restriction: They can only be declared at package level. | |
| </p> | |
| <p> | |
| The type of a method is the type of a function with the receiver as first | |
| argument. For instance, the method <code>Scale</code> has type | |
| </p> | |
| <pre> | |
| (p *Point, factor float) | |
| </pre> | |
| <p> | |
| However, a function declared this way is not a method. | |
| </p> | |
| <h3>Forward declarations</h3> | |
| <p> | |
| Mutually-recursive types require that one be | |
| <i>forward declared</i> so that it may be named in the other. | |
| A forward declaration of a type omits the block containing the fields | |
| or methods of the type. | |
| </p> | |
| <pre> | |
| type List struct // forward declaration of List | |
| type Item struct { | |
| value int; | |
| next *List; | |
| } | |
| type List struct { | |
| head, tail *Item | |
| } | |
| </pre> | |
| <p> | |
| A forward-declared type is incomplete (§Types) | |
| until it is fully declared. The full declaration must follow | |
| before the end of the block containing the forward declaration; | |
| it cannot be contained in an inner block. | |
| </p> | |
| <p> | |
| Functions and methods may similarly be forward-declared by omitting their body. | |
| </p> | |
| <pre> | |
| func F(a int) int // forward declaration of F | |
| func G(a, b int) int { | |
| return F(a) + F(b) | |
| } | |
| func F(a int) int { | |
| if a <= 0 { return 0 } | |
| return G(a-1, b+1) | |
| } | |
| </pre> | |
| <hr/> | |
| <h2>Expressions</h2> | |
| <p> | |
| An expression specifies the computation of a value by applying | |
| operators and functions to operands. An expression has a value and | |
| a type. | |
| </p> | |
| <h3>Operands</h3> | |
| Operands denote the elementary values in an expression. | |
| <pre class="grammar"> | |
| Operand = Literal | QualifiedIdent | "(" Expression ")" . | |
| Literal = BasicLit | CompositeLit | FunctionLit . | |
| BasicLit = int_lit | float_lit | char_lit | StringLit . | |
| StringLit = string_lit { string_lit } . | |
| </pre> | |
| <h3>Constants</h3> | |
| <p> | |
| A <i>constant</i> is a literal of a basic type | |
| (including the predeclared constants <code>true</code>, <code>false</code> | |
| and <code>nil</code> | |
| and values denoted by <code>iota</code>) | |
| or a constant expression (§Constant expressions). | |
| Constants have values that are known at compile time. | |
| </p> | |
| <h3>Qualified identifiers</h3> | |
| <p> | |
| A qualified identifier is an identifier qualified by a package name prefix. | |
| </p> | |
| <pre class="grammar"> | |
| QualifiedIdent = [ ( LocalPackageName | PackageName ) "." ] identifier . | |
| LocalPackageName = identifier . | |
| PackageName = identifier . | |
| </pre> | |
| <p> | |
| A qualified identifier accesses an identifier in | |
| a separate package. The identifier must be exported by that package, which | |
| means that it must begin with a Unicode upper case letter (§Exported identifiers). | |
| </p> | |
| <p> | |
| The LocalPackageName is that of the package in which the qualified identifier | |
| appears and is only necessary to access names hidden by intervening declarations | |
| of a package-level identifier. | |
| </p> | |
| <pre> | |
| Math.Sin | |
| mypackage.hiddenName | |
| mypackage.Math.Sin // if Math is declared in an intervening scope | |
| </pre> | |
| TODO: 6g does not implement LocalPackageName. Is this new? | |
| Is it needed? | |
| <h3>Composite literals</h3> | |
| <p> | |
| Composite literals construct values for structs, arrays, slices, and maps | |
| and create a new value each time they are evaluated. | |
| They consist of the type of the value | |
| followed by a brace-bound list of expressions, | |
| or a list of key-value pairs for map literals. | |
| </p> | |
| <pre class="grammar"> | |
| CompositeLit = LiteralType "{" [ ( ExpressionList | KeyValueList ) [ "," ] ] "}" . | |
| LiteralType = StructType | ArrayType | "[" "..." "]" ElementType | | |
| SliceType | MapType | TypeName . | |
| KeyValueList = KeyValueExpr { "," KeyValueExpr } . | |
| KeyValueExpr = Expression ":" Expression . | |
| </pre> | |
| <p> | |
| The LiteralType must be a struct, array, slice, or map type. | |
| (The grammar enforces this constraint except when the type is given | |
| as a TypeName.) | |
| The types of the expressions must be assignment compatible to | |
| the respective field, element, and key types of the LiteralType; | |
| there is no additional conversion. | |
| </p> | |
| <pre> | |
| type Rat struct { num, den int } | |
| type Num struct { r Rat; f float; s string } | |
| </pre> | |
| <p> | |
| one may write | |
| </p> | |
| <pre> | |
| pi := Num{Rat{22, 7}, 3.14159, "pi"} | |
| </pre> | |
| <p> | |
| Taking the address of a composite literal (§Address operators) | |
| generates a unique pointer to an instance of the literal's value. | |
| </p> | |
| <pre> | |
| var pi_ptr *Rat = &Rat{22, 7} | |
| </pre> | |
| <p> | |
| The length of an array literal is the length specified in the LiteralType. | |
| If fewer elements than the length are provided in the literal, the missing | |
| elements are set to the zero value for the array element type. | |
| It is an error to provide more elements than specified in the type. The | |
| notation <code>...</code> specifies an array length equal | |
| to the number of elements in the literal. | |
| </p> | |
| <pre> | |
| buffer := [10]string{}; // len(buffer) == 10 | |
| primes := [6]int{2, 3, 5, 7, 9, 11}; // len(primes) == 6 | |
| days := [...]string{"Sat", "Sun"}; // len(days) == 2 | |
| </pre> | |
| <p> | |
| A slice literal describes the entire underlying array literal. | |
| Thus, the length and capacity of a slice literal is the number of elements | |
| (of the array) provided in the literal. A slice literal has the form | |
| </p> | |
| <pre> | |
| []T{x1, x2, ... xn} | |
| </pre> | |
| <p> | |
| and is a shortcut for a slice operation applied to an array literal: | |
| </p> | |
| <pre> | |
| [n]T{x1, x2, ... xn}[0 : n] | |
| </pre> | |
| <p> | |
| In map literals only, the list contains | |
| key-value pairs separated by a colon: | |
| </p> | |
| <pre> | |
| m := map[string]int{"good": 0, "bad": 1, "indifferent": 7}; | |
| </pre> | |
| <p> | |
| A parsing ambiguity arises when a composite literal using the | |
| TypeName form of the LiteralType appears in the condition of an | |
| "if", "for", or "switch" statement, because the braces surrounding | |
| the expressions in the literal are confused with those introducing | |
| a block of statements. To resolve the ambiguity in this rare case, | |
| the composite literal must appear within | |
| parentheses. | |
| </p> | |
| <pre> | |
| if x == (T{a,b,c}[i]) { ... } | |
| if (x == T{a,b,c}[i]) { ... } | |
| </pre> | |
| <h3>Function literals</h3> | |
| <p> | |
| A function literal represents an anonymous function. | |
| It consists of a specification of the function type and a function body. | |
| </p> | |
| <pre class="grammar"> | |
| FunctionLit = FunctionType Block . | |
| Block = "{" StatementList "}" . | |
| </pre> | |
| <pre> | |
| func (a, b int, z float) bool { return a*b < int(z) } | |
| </pre> | |
| <p> | |
| A function literal can be assigned to a variable or invoked directly. | |
| </p> | |
| <pre> | |
| f := func(x, y int) int { return x + y } | |
| func(ch chan int) { ch <- ACK } (reply_chan) | |
| </pre> | |
| <p> | |
| Function literals are <i>closures</i>: they may refer to variables | |
| defined in a surrounding function. Those variables are then shared between | |
| the surrounding function and the function literal, and they survive as long | |
| as they are accessible. | |
| </p> | |
| <h3>Primary expressions</h3> | |
| <pre class="grammar"> | |
| PrimaryExpr = | |
| Operand | | |
| PrimaryExpr Selector | | |
| PrimaryExpr Index | | |
| PrimaryExpr Slice | | |
| PrimaryExpr TypeAssertion | | |
| PrimaryExpr Call . | |
| Selector = "." identifier . | |
| Index = "[" Expression "]" . | |
| Slice = "[" Expression ":" Expression "]" . | |
| TypeAssertion = "." "(" Type ")" . | |
| Call = "(" [ ExpressionList ] ")" . | |
| </pre> | |
| <pre> | |
| x | |
| 2 | |
| (s + ".txt") | |
| f(3.1415, true) | |
| Point{1, 2} | |
| m["foo"] | |
| s[i : j + 1] | |
| obj.color | |
| Math.sin | |
| f.p[i].x() | |
| </pre> | |
| <h3>Selectors</h3> | |
| <p> | |
| A primary expression of the form | |
| </p> | |
| <pre> | |
| x.f | |
| </pre> | |
| <p> | |
| denotes the field or method <code>f</code> of the value denoted by <code>x</code> | |
| (or of <code>*x</code> if | |
| <code>x</code> is of pointer type). The identifier <code>f</code> | |
| is called the (field or method) | |
| <i>selector</i>. | |
| The type of the expression is the type of <code>f</code>. | |
| </p> | |
| <p> | |
| A selector <code>f</code> may denote a field or method <code>f</code> of | |
| a type <code>T</code>, or it may refer | |
| to a field or method <code>f</code> of a nested anonymous field of | |
| <code>T</code>. | |
| The number of anonymous fields traversed | |
| to reach <code>f</code> is called its <i>depth</i> in <code>T</code>. | |
| The depth of a field or method <code>f</code> | |
| declared in <code>T</code> is zero. | |
| The depth of a field or method <code>f</code> declared in | |
| an anonymous field <code>A</code> in <code>T</code> is the | |
| depth of <code>f</code> in <code>A</code> plus one. | |
| </p> | |
| <p> | |
| The following rules apply to selectors: | |
| </p> | |
| <ol> | |
| <li> | |
| For a value <code>x</code> of type <code>T</code> or <code>*T</code> | |
| where <code>T</code> is not an interface type, | |
| <code>x.f</code> denotes the field or method at the shallowest depth | |
| in <code>T</code> where there | |
| is such an <code>f</code>. | |
| If there is not exactly one <code>f</code> with shallowest depth, the selector | |
| expression is illegal. | |
| </li> | |
| <li> | |
| For a variable <code>x</code> of type <code>I</code> or <code>*I</code> | |
| where <code>I</code> is an interface type, | |
| <code>x.f</code> denotes the actual method with name <code>f</code> of the value assigned | |
| to <code>x</code> if there is such a method. | |
| If no value or <code>nil</code> was assigned to <code>x</code>, <code>x.f</code> is illegal. | |
| </li> | |
| <li> | |
| In all other cases, <code>x.f</code> is illegal. | |
| </ol> | |
| <p> | |
| Selectors automatically dereference pointers as necessary. | |
| If <code>x</code> is of pointer type, <code>x.y</code> | |
| is shorthand for <code>(*x).y</code>; if <code>y</code> | |
| is also of pointer type, <code>x.y.z</code> is shorthand | |
| for <code>(*(*x).y).z</code>, and so on. | |
| If <code>*x</code> is of pointer type, dereferencing | |
| must be explicit; | |
| only one level of automatic dereferencing is provided. | |
| For an <code>x</code> of type <code>T</code> containing an | |
| anonymous field declared as <code>*A</code>, | |
| <code>x.f</code> is a shortcut for <code>(*x.A).f</code>. | |
| </p> | |
| <p> | |
| For example, given the declarations: | |
| </p> | |
| <pre> | |
| type T0 struct { | |
| x int; | |
| } | |
| func (recv *T0) M0() | |
| type T1 struct { | |
| y int; | |
| } | |
| func (recv T1) M1() | |
| type T2 struct { | |
| z int; | |
| T1; | |
| *T0; | |
| } | |
| func (recv *T2) M2() | |
| var p *T2; // with p != nil and p.T1 != nil | |
| </pre> | |
| <p> | |
| one may write: | |
| </p> | |
| <pre> | |
| p.z // (*p).z | |
| p.y // ((*p).T1).y | |
| p.x // (*(*p).T0).x | |
| p.M2 // (*p).M2 | |
| p.M1 // ((*p).T1).M1 | |
| p.M0 // ((*p).T0).M0 | |
| </pre> | |
| <font color=red> | |
| TODO: Specify what happens to receivers. | |
| </font> | |
| <h3>Indexes</h3> | |
| <p> | |
| A primary expression of the form | |
| </p> | |
| <pre> | |
| a[x] | |
| </pre> | |
| <p> | |
| denotes the array or map element of <code>a</code> indexed by <code>x</code>. | |
| The value <code>x</code> is called the | |
| <i>array index</i> or <i>map key</i>, respectively. The following | |
| rules apply: | |
| </p> | |
| <p> | |
| For <code>a</code> of type <code>A</code> or <code>*A</code> | |
| where <code>A</code> is an array type (§Array types): | |
| </p> | |
| <ul> | |
| <li><code>x</code> must be an integer value and <code>0 <= x < len(a)</code> | |
| <li><code>a[x]</code> is the array element at index <code>x</code> and the type of | |
| <code>a[x]</code> is the element type of <code>A</code> | |
| </ul> | |
| <p> | |
| For <code>a</code> of type <code>M</code> or <code>*M</code> | |
| where <code>M</code> is a map type (§Map types): | |
| </p> | |
| <ul> | |
| <li><code>x</code>'s type must be equal to the key type of <code>M</code> | |
| and the map must contain an entry with key <code>x</code> (but see special forms below) | |
| <li><code>a[x]</code> is the map value with key <code>x</code> | |
| and the type of <code>a[x]</code> is the value type of <code>M</code> | |
| </ul> | |
| <p> | |
| Otherwise <code>a[x]</code> is illegal. If the index or key is out of range evaluating | |
| an otherwise legal index expression, a run-time exception occurs. | |
| </p> | |
| <p> | |
| However, if an index expression on a map <code>a</code> of type <code>map[K] V</code> | |
| is used in an assignment of one of the special forms | |
| </p> | |
| <pre> | |
| r, ok = a[x] | |
| r, ok := a[x] | |
| </pre> | |
| <p> | |
| the result of the index expression is a pair of values with types | |
| <code>(K, bool)</code>. | |
| If the key is present in the map, | |
| the expression returns the pair <code>(a[x], true)</code>; | |
| otherwise it returns <code>(Z, false)</code> where <code>Z</code> is | |
| the zero value for <code>V</code> (§The zero value). | |
| No run-time exception occurs in this case. | |
| The index expression in this construct thus acts like a function call | |
| returning a value and a boolean indicating success. (§Assignments) | |
| </p> | |
| <p> | |
| Similarly, if an assignment to a map has the special form | |
| </p> | |
| <pre> | |
| a[x] = r, ok | |
| </pre> | |
| <p> | |
| and boolean <code>ok</code> has the value <code>false</code>, | |
| the entry for key <code>x</code> is deleted from the map; if | |
| <code>ok</code> is <code>true</code>, the construct acts like | |
| a regular assignment to an element of the map. | |
| </p> | |
| <h3>Slices</h3> | |
| <p> | |
| Strings, arrays, and slices can be <i>sliced</i> to construct substrings or descriptors | |
| of subarrays. The index expressions in the slice select which elements appear | |
| in the result. The result has indexes starting at 0 and length equal to the | |
| difference in the index values in the slice. After slicing the array <code>a</code> | |
| </p> | |
| <pre> | |
| a := [4]int{1, 2, 3, 4}; | |
| s := a[1:3]; | |
| </pre> | |
| <p> | |
| the slice <code>s</code> has type <code>[]int</code>, length 2, capacity 3, and elements | |
| </p> | |
| <pre> | |
| s[0] == 2 | |
| s[1] == 3 | |
| </pre> | |
| <p> | |
| The slice length must be non-negative. | |
| For arrays or strings, the indexes | |
| <code>lo</code> and <code>hi</code> must satisfy | |
| 0 <= <code>lo</code> <= <code>hi</code> <= length; | |
| for slices, the upper bound is the capacity rather than the length. | |
| <p> | |
| If the sliced operand is a string, the result of the slice operation is another, new | |
| string (§String types). If the sliced operand is an array or slice, the result | |
| of the slice operation is a slice (§Slice types). | |
| </p> | |
| <h3>Type assertions</h3> | |
| <p> | |
| For an expression <code>x</code> and a type <code>T</code>, the primary expression | |
| </p> | |
| <pre> | |
| x.(T) | |
| </pre> | |
| <p> | |
| asserts that the value stored in <code>x</code> is of type <code>T</code>. | |
| The notation <code>x.(T)</code> is called a <i>type assertion</i>. | |
| The type of <code>x</code> must be an interface type. | |
| </p> | |
| <p> | |
| More precisely, if <code>T</code> is not an interface type, <code>x.(T)</code> asserts | |
| that the dynamic type of <code>x</code> is identical to the type <code>T</code> | |
| (§Type equality and identity). | |
| If <code>T</code> is an interface type, <code>x.(T)</code> asserts that the dynamic type | |
| of <code>T</code> implements the interface <code>T</code> (§Interface types). | |
| <font color=red>TODO: gri wants an error if x is already of type T.</font> | |
| </p> | |
| <p> | |
| If the type assertion holds, the value of the expression is the value | |
| stored in <code>x</code> and its type is <code>T</code>. If the type assertion is false, a run-time | |
| exception occurs. In other words, even though the dynamic type of <code>x</code> | |
| is known only at run-time, the type of <code>x.(T)</code> is | |
| known to be <code>T</code> in a correct program. | |
| </p> | |
| <p> | |
| If a type assertion is used in an assignment of one of the special forms, | |
| </p> | |
| <pre> | |
| v, ok = x.(T) | |
| v, ok := x.(T) | |
| </pre> | |
| <p> | |
| the result of the assertion is a pair of values with types <code>(T, bool)</code>. | |
| If the assertion holds, the expression returns the pair <code>(x.(T), true)</code>; | |
| otherwise, the expression returns <code>(Z, false)</code> where <code>Z</code> | |
| is the zero value for type <code>T</code> (§The zero value). | |
| No run-time exception occurs in this case. | |
| The type assertion in this construct thus acts like a function call | |
| returning a value and a boolean indicating success. (§Assignments) | |
| </p> | |
| <h3>Calls</h3> | |
| <p> | |
| Given an expression <code>f</code> of function type | |
| <code>F</code>, | |
| </p> | |
| <pre> | |
| f(a1, a2, ... an) | |
| </pre> | |
| <p> | |
| calls <code>f</code> with arguments <code>a1, a2, ... an</code>. | |
| The arguments must be single-valued expressions | |
| assignment compatible with the parameters of | |
| <code>F</code> and are evaluated before the function is called. | |
| The type of the expression is the result type | |
| of <code>F</code>. | |
| A method invocation is similar but the method itself | |
| is specified as a selector upon a value of the receiver type for | |
| the method. | |
| </p> | |
| <pre> | |
| Atan2(x, y) // function call | |
| var pt *Point; | |
| pt.Scale(3.5) // method call with receiver pt | |
| </pre> | |
| <p> | |
| If the receiver type of the method is declared as a pointer of type <code>*T</code>, | |
| the actual receiver may be a value of type <code>T</code>; | |
| in such cases method invocation implicitly takes the | |
| receiver's address: | |
| </p> | |
| <pre> | |
| var p Point; | |
| p.Scale(3.5) | |
| </pre> | |
| <p> | |
| There is no distinct method type and there are no method literals. | |
| </p> | |
| <h3>Passing arguments to <code>...</code> parameters</h3> | |
| <p> | |
| When a function <code>f</code> has a <code>...</code> parameter, | |
| it is always the last formal parameter. Within calls to <code>f</code>, | |
| the arguments before the <code>...</code> are treated normally. | |
| After those, an arbitrary number (including zero) of trailing | |
| arguments may appear in the call and are bound to the <code>...</code> | |
| parameter. | |
| </p> | |
| <p> | |
| Within <code>f</code>, the <code>...</code> parameter has static | |
| type <code>interface{}</code> (the empty interface). For each call, | |
| its dynamic type is a structure whose sequential fields are the | |
| trailing arguments of the call. That is, the actual arguments | |
| provided for a <code>...</code> parameter are wrapped into a struct | |
| that is passed to the function instead of the actual arguments. | |
| Using the reflection library (TODO: reference), <code>f</code> may | |
| unpack the elements of the dynamic type to recover the actual | |
| arguments. | |
| </p> | |
| <p> | |
| Given the function and call | |
| </p> | |
| <pre> | |
| func Fprintf(f io.Write, format string, args ...) | |
| Fprintf(os.Stdout, "%s %d", "hello", 23); | |
| </pre> | |
| <p> | |
| Within <code>Fprintf</code>, the dynamic type of <code>args</code> for this | |
| call will be, schematically, | |
| <code> struct { string; int }</code>. | |
| </p> | |
| <p> | |
| As a special case, if a function passes its own <code>...</code> parameter as the argument | |
| for a <code>...</code> in a call to another function with a <code>...</code> parameter, | |
| the parameter is not wrapped again but passed directly. In short, a formal <code>...</code> | |
| parameter is passed unchanged as an actual <code>...</code> parameter. | |
| <h3>Operators</h3> | |
| <p> | |
| Operators combine operands into expressions. | |
| </p> | |
| <pre class="grammar"> | |
| Expression = UnaryExpr | Expression binary_op UnaryExpr . | |
| UnaryExpr = PrimaryExpr | unary_op UnaryExpr . | |
| binary_op = log_op | com_op | rel_op | add_op | mul_op . | |
| log_op = "||" | "&&" . | |
| com_op = "<-" . | |
| rel_op = "==" | "!=" | "<" | "<=" | ">" | ">=" . | |
| add_op = "+" | "-" | "|" | "^" . | |
| mul_op = "*" | "/" | "%" | "<<" | ">>" | "&" | "&^" . | |
| unary_op = "+" | "-" | "!" | "^" | "*" | "&" | "<-" . | |
| </pre> | |
| <p> | |
| The operand types in binary operations must be equal, with the following exceptions: | |
| </p> | |
| <ul> | |
| <li>Except in shift expressions, if one operand has numeric type and the other operand is | |
| an ideal number, the ideal number is converted to match the type of | |
| the other operand (§Expressions).</li> | |
| <li>If both operands are ideal numbers, the conversion is to ideal floats | |
| if one of the operands is an ideal float | |
| (relevant for <code>/</code> and <code>%</code>).</li> | |
| <li>The right operand in a shift operation must be always be of unsigned integer type | |
| or an ideal number that can be safely converted into an unsigned integer type | |
| (§Arithmetic operators).</li> | |
| <li>The operands in channel sends differ in type: one is always a channel and the | |
| other is a variable or value of the channel's element type.</li> | |
| <li>When comparing two operands of channel type, the channel value types | |
| must be equal but the channel direction is ignored.</li> | |
| </ul> | |
| <p> | |
| Unary operators have the highest precedence. They are evaluated from | |
| right to left. As the <code>++</code> and <code>--</code> operators form | |
| statements, not expressions, they fall | |
| outside the unary operator hierarchy and apply | |
| to the operand on the left. | |
| As a consequence, statement <code>*p++</code> is the same as <code>(*p)++</code>. | |
| <p> | |
| There are six precedence levels for binary operators. | |
| Multiplication operators bind strongest, followed by addition | |
| operators, comparison operators, communication operators, | |
| <code>&&</code> (logical and), and finally <code>||</code> (logical or): | |
| </p> | |
| <pre class="grammar"> | |
| Precedence Operator | |
| 6 * / % << >> & &^ | |
| 5 + - | ^ | |
| 4 == != < <= > >= | |
| 3 <- | |
| 2 && | |
| 1 || | |
| </pre> | |
| <p> | |
| Binary operators of the same precedence associate from left to right. | |
| For instance, <code>x / y / z</code> is the same as <code>(x / y) / z</code>. | |
| </p> | |
| <p> | |
| Examples: | |
| </p> | |
| <pre> | |
| +x | |
| 23 + 3*x[i] | |
| x <= f() | |
| ^a >> b | |
| f() || g() | |
| x == y + 1 && <-chan_ptr > 0 | |
| </pre> | |
| <h3>Arithmetic operators</h3> | |
| <p> | |
| Arithmetic operators apply to numeric types and yield a result of the same | |
| type as the first operand. The four standard arithmetic operators (<code>+</code>, | |
| <code>-</code>, <code>*</code>, <code>/</code>) apply both to integer and | |
| floating point types, while <code>+</code> applies also | |
| to strings; all other arithmetic operators apply to integers only. | |
| </p> | |
| <pre class="grammar"> | |
| + sum integers, floats, strings | |
| - difference integers, floats | |
| * product integers, floats | |
| / quotient integers, floats | |
| % remainder integers | |
| & bitwise and integers | |
| | bitwise or integers | |
| ^ bitwise xor integers | |
| &^ bit clear (and not) integers | |
| << left shift integer << unsigned integer | |
| >> right shift integer >> unsigned integer | |
| </pre> | |
| <p> | |
| Strings can be concatenated using the <code>+</code> operator | |
| or the <code>+=</code> assignment operator: | |
| </p> | |
| <pre> | |
| s := "hi" + string(c); | |
| s += " and good bye"; | |
| </pre> | |
| <p> | |
| String addition creates a new string by concatenating the operands. | |
| </p> | |
| <p> | |
| For integer values, <code>/</code> and <code>%</code> satisfy the following relationship: | |
| </p> | |
| <pre> | |
| (a / b) * b + a % b == a | |
| </pre> | |
| <p> | |
| with <code>(a / b)</code> truncated towards zero. | |
| Examples: | |
| </p> | |
| <pre> | |
| x y x / y x % y | |
| 5 3 1 2 | |
| -5 3 -1 -2 | |
| 5 -3 -1 2 | |
| -5 -3 1 -2 | |
| </pre> | |
| <p> | |
| If the dividend is positive and the divisor is a constant power of 2, | |
| the division may be replaced by a left shift, and computing the remainder may | |
| be replaced by a bitwise "and" operation: | |
| </p> | |
| <pre> | |
| x x / 4 x % 4 x >> 2 x & 3 | |
| 11 2 3 2 3 | |
| -11 -2 -3 -3 1 | |
| </pre> | |
| <p> | |
| The shift operators shift the left operand by the shift count specified by the | |
| right operand. They implement arithmetic shifts if the left operand is a signed | |
| integer and logical shifts if it is an unsigned integer. The shift count must | |
| be an unsigned integer. There is no upper limit on the shift count. Shifts behave | |
| as if the left operand is shifted <code>n</code> times by 1 for a shift | |
| count of <code>n</code>. | |
| As a result, <code>x << 1</code> is the same as <code>x*2</code> | |
| and <code>x >> 1</code> is the same as | |
| <code>x/2</code> truncated towards negative infinity. | |
| </p> | |
| <p> | |
| For integer operands, the unary operators | |
| <code>+</code>, <code>-</code>, and <code>^</code> are defined as | |
| follows: | |
| </p> | |
| <pre class="grammar"> | |
| +x is 0 + x | |
| -x negation is 0 - x | |
| ^x bitwise complement is m ^ x with m = "all bits set to 1" | |
| </pre> | |
| <p> | |
| For floating point numbers, | |
| <code>+x</code> is the same as <code>x</code>, | |
| while <code>-x</code> is the negation of <code>x</code>. | |
| </p> | |
| <h3>Integer overflow</h3> | |
| <p> | |
| For unsigned integer values, the operations <code>+</code>, | |
| <code>-</code>, <code>*</code>, and <code><<</code> are | |
| computed modulo 2<sup><i>n</i></sup>, where <i>n</i> is the bit width of | |
| the unsigned integer's type | |
| (§Numeric types). Loosely speaking, these unsigned integer operations | |
| discard high bits upon overflow, and programs may rely on ``wrap around''. | |
| </p> | |
| <p> | |
| For signed integers, the operations <code>+</code>, | |
| <code>-</code>, <code>*</code>, and <code><<</code> may legally | |
| overflow and the resulting value exists and is deterministically defined | |
| by the signed integer representation, the operation, and its operands. | |
| No exception is raised as a result of overflow. A | |
| compiler may not optimize code under the assumption that overflow does | |
| not occur. For instance, it may not assume that <code>x < x + 1</code> is always true. | |
| </p> | |
| <h3>Comparison operators</h3> | |
| <p> | |
| Comparison operators yield a boolean result. All comparison operators apply | |
| to basic types except bools. | |
| The operators <code>==</code> and <code>!=</code> apply, at least in some cases, | |
| to all types except arrays and structs. | |
| </p> | |
| <pre class="grammar"> | |
| == equal | |
| != not equal | |
| < less | |
| <= less or equal | |
| > greater | |
| >= greater or equal | |
| </pre> | |
| <p> | |
| Numeric basic types are compared in the usual way. | |
| </p> | |
| <p> | |
| Strings are compared byte-wise (lexically). | |
| </p> | |
| <p> | |
| Booleans are equal if they are either both "true" or both "false". | |
| </p> | |
| <p> | |
| The rules for comparison of composite types are described in the | |
| section on §Comparison compatibility. | |
| </p> | |
| <h3>Logical operators</h3> | |
| <p> | |
| Logical operators apply to boolean operands and yield a boolean result. | |
| The right operand is evaluated conditionally. | |
| </p> | |
| <pre class="grammar"> | |
| && conditional and p && q is "if p then q else false" | |
| || conditional or p || q is "if p then true else q" | |
| ! not !p is "not p" | |
| </pre> | |
| <h3>Address operators</h3> | |
| <p> | |
| The unary prefix address-of operator <code>&</code> generates the address of its operand, which must be a variable, | |
| pointer indirection, field selector, or array or slice indexing operation. It is illegal to take the address of a function | |
| result variable. | |
| Given an operand of pointer type, the unary prefix pointer indirection operator <code>*</code> retrieves the value pointed | |
| to by the operand. | |
| </p> | |
| <pre> | |
| &x | |
| &a[f(2)] | |
| *p | |
| *pf(x) | |
| </pre> | |
| <p> | |
| <font color=red>TODO: This text needs to be cleaned up and go elsewhere, there are no address | |
| operators involved. | |
| </font> | |
| </p> | |
| <p> | |
| Methods are a form of function and a method ``value'' has a function type. | |
| Consider the type T with method M: | |
| </p> | |
| <pre> | |
| type T struct { | |
| a int; | |
| } | |
| func (tp *T) M(a int) int; | |
| var t *T; | |
| </pre> | |
| <p> | |
| To construct the value of method M, one writes | |
| </p> | |
| <pre> | |
| t.M | |
| </pre> | |
| <p> | |
| using the variable t (not the type T). | |
| <font color=red>TODO: It makes perfect sense to be able to say T.M (in fact, it makes more | |
| sense then t.M, since only the type T is needed to find the method M, i.e., | |
| its address). TBD. | |
| </font> | |
| </p> | |
| <p> | |
| The expression t.M is a function value with type | |
| </p> | |
| <pre> | |
| func (t *T, a int) int | |
| </pre> | |
| <p> | |
| and may be invoked only as a function, not as a method: | |
| </p> | |
| <pre> | |
| var f func (t *T, a int) int; | |
| f = t.M; | |
| x := f(t, 7); | |
| </pre> | |
| <p> | |
| Note that one does not write t.f(7); taking the value of a method demotes | |
| it to a function. | |
| </p> | |
| <p> | |
| In general, given type T with method M and variable t of type T, | |
| the method invocation | |
| </p> | |
| <pre> | |
| t.M(args) | |
| </pre> | |
| <p> | |
| is equivalent to the function call | |
| </p> | |
| <pre> | |
| (t.M)(t, args) | |
| </pre> | |
| <p> | |
| <font color=red> | |
| TODO: should probably describe the effect of (t.m) under §Expressions if t.m | |
| denotes a method: Effect is as described above, converts into function. | |
| </font> | |
| </p> | |
| <p> | |
| If T is an interface type, the expression t.M does not determine which | |
| underlying type's M is called until the point of the call itself. Thus given | |
| T1 and T2, both implementing interface I with method M, the sequence | |
| </p> | |
| <pre> | |
| var t1 *T1; | |
| var t2 *T2; | |
| var i I = t1; | |
| m := i.M; | |
| m(t2, 7); | |
| </pre> | |
| <p> | |
| will invoke t2.M() even though m was constructed with an expression involving | |
| t1. Effectively, the value of m is a function literal | |
| </p> | |
| <pre> | |
| func (recv I, a int) { | |
| recv.M(a); | |
| } | |
| </pre> | |
| <p> | |
| that is automatically created. | |
| </p> | |
| <p> | |
| <font color=red> | |
| TODO: Document implementation restriction: It is illegal to take the address | |
| of a result parameter (e.g.: func f() (x int, p *int) { return 2, &x }). | |
| (TBD: is it an implementation restriction or fact?) | |
| </font> | |
| </p> | |
| <h3>Communication operators</h3> | |
| <p> | |
| The term <i>channel</i> means "variable of channel type" (§Channel types). | |
| </p> | |
| <p> | |
| The send operation uses the binary operator "<-", which operates on | |
| a channel and a value (expression): | |
| </p> | |
| <pre> | |
| ch <- 3 | |
| </pre> | |
| <p> | |
| The send operation sends the value on the channel. Both the channel | |
| and the expression are evaluated before communication begins. | |
| Communication blocks until the send can proceed, at which point the | |
| value is transmitted on the channel. A send can proceed if the | |
| channel is asynchronous and there is room in its buffer or the | |
| channel is synchronous and a receiver is ready. | |
| </p> | |
| <p> | |
| If the send operation appears in an expression context, the value | |
| of the expression is a boolean and the operation is non-blocking. | |
| The value of the boolean reports true if the communication succeeded, | |
| false if it did not. (The channel and | |
| the expression to be sent are evaluated regardless.) | |
| These two examples are equivalent: | |
| </p> | |
| <pre> | |
| ok := ch <- 3; | |
| if ok { print("sent") } else { print("not sent") } | |
| if ch <- 3 { print("sent") } else { print("not sent") } | |
| </pre> | |
| <p> | |
| In other words, if the program tests the value of a send operation, | |
| the send is non-blocking and the value of the expression is the | |
| success of the operation. If the program does not test the value, | |
| the operation blocks until it succeeds. | |
| </p> | |
| <p> | |
| The receive operation uses the prefix unary operator "<-". | |
| The value of the expression is the value received, whose type | |
| is the element type of the channel. | |
| </p> | |
| <pre> | |
| <-ch | |
| </pre> | |
| <p> | |
| The expression blocks until a value is available, which then can | |
| be assigned to a variable or used like any other expression. | |
| If the receive expression does not save the value, the value is | |
| discarded. | |
| </p> | |
| <pre> | |
| v1 := <-ch | |
| v2 = <-ch | |
| f(<-ch) | |
| <-strobe // wait until clock pulse | |
| </pre> | |
| <p> | |
| If a receive expression is used in a tuple assignment of the form | |
| </p> | |
| <pre> | |
| x, ok = <-ch; // or: x, ok := <-ch | |
| </pre> | |
| <p> | |
| the receive operation becomes non-blocking. | |
| If the operation can proceeed, the boolean variable | |
| <code>ok</code> will be set to <code>true</code> | |
| and the value stored in <code>x</code>; otherwise | |
| <code>ok</code> is set | |
| to <code>false</code> and <code>x</code> is set to the | |
| zero value for its type (§The zero value). | |
| </p> | |
| <p> | |
| <font color=red>TODO: Probably in a separate section, communication semantices | |
| need to be presented regarding send, receive, select, and goroutines.</font> | |
| </p> | |
| <h3>Constant expressions</h3> | |
| <p> | |
| Constant expressions may contain only constants, <code>iota</code>, | |
| numeric literals, string literals, and | |
| some constant-valued built-in functions such as <code>unsafe.Sizeof</code> | |
| and <code>len</code> applied to an array. | |
| In practice, constant expressions are those that can be evaluated at compile time. | |
| <p> | |
| The type of a constant expression is determined by the type of its | |
| elements. If it contains only numeric literals, its type is <i>ideal | |
| integer</i> or <i>ideal float</i> (§Ideal number). Whether a literal | |
| is an integer or float depends on the syntax of the literals (123 vs. 123.0). | |
| The nature of the arithmetic | |
| operations within the expression depends, elementwise, on the values; | |
| for example, 3/2 is an integer division yielding 1, while 3./2. is | |
| a floating point division yielding 1.5. Thus | |
| </p> | |
| <pre> | |
| const x = 3./2. + 3/2; | |
| </pre> | |
| <p> | |
| yields a floating point constant of ideal float value 2.5 (1.5 + | |
| 1); its constituent expressions are evaluated using distinct rules | |
| for division. | |
| </p> | |
| <p> | |
| Intermediate values and the constants themselves | |
| may require precision significantly larger than any concrete type | |
| in the language. The following are legal declarations: | |
| </p> | |
| <pre> | |
| const Huge = 1 << 100; | |
| const Four int8 = Huge >> 98; | |
| </pre> | |
| <p> | |
| A constant expression may appear in any context, such as assignment | |
| to a variable of any numeric type, as long as the value of the | |
| expression can be represented accurately in that context. | |
| It is erroneous to assign a value with a non-zero fractional part | |
| to an integer, or if the assignment would overflow or underflow, | |
| or in general if the value cannot be represented by the type of | |
| the variable. | |
| For | |
| instance, <code>3</code> can be assigned to any integer variable but also to any | |
| floating point variable, while <code>-1e12</code> can be assigned to a | |
| <code>float32</code>, <code>float64</code>, or even <code>int64</code> | |
| but not <code>uint64</code> or <code>string</code>. | |
| </p> | |
| <p> | |
| If a typed constant expression evaluates to a value that is not | |
| representable by that type, the compiler reports an error. | |
| </p> | |
| <pre> | |
| uint8(-1) // error, out of range | |
| uint8(100) * 100 // error, out of range | |
| </pre> | |
| <p> | |
| The size of the mask used by the unary bitwise complement | |
| operator in a typed constant expression is equal to the size of the | |
| expression's type. In an ideal constant expression, the bitwise | |
| complement operator inverts all the bits, producing a negative value. | |
| </p> | |
| <pre> | |
| ^1 // ideal constant, equal to -2 | |
| uint8(^1) // error, same as uint8(-2), out of range | |
| ^uint8(1) // typed uint8 constant, same as 0xFF ^ uint8(1) = uint8(0xFE) | |
| int8(^1) // same as int8(-2) | |
| ^int8(1) // error, same as 0xFF ^ int8(1) = int8(0xFE), out of range | |
| </pre> | |
| <p> | |
| TODO: perhaps ^ should be disallowed on non-uints instead of assuming twos complement. | |
| Also it may be possible to make typed constants more like variables, at the cost of fewer | |
| overflow etc. errors being caught. | |
| </p> | |
| <h3>Order of evaluation</h3> | |
| <p> | |
| When evaluating the elements of an assignment or expression, | |
| all function calls, method calls and | |
| communication operations are evaluated in lexical left-to-right | |
| order. Otherwise, the order of evaluation is unspecified. | |
| </p> | |
| <p> | |
| For example, while evaluating the arguments for this call | |
| to function <code>f</code>, | |
| </p> | |
| <pre> | |
| f(g(), h() + x[i()], <-c) | |
| </pre> | |
| <p> | |
| the call to <code>g()</code> happens before the call to <code>h()</code>, | |
| which happens before the call to <code>i()</code>, all of | |
| of which happen before receiving the value from the channel | |
| <code>c</code>. | |
| However, the order of those events compared to the evaluation of | |
| <code>f</code>, the evaluation of <code>x</code>, and the indexing | |
| of <code>x</code> by the return value of | |
| <code>i()</code> is not specified. | |
| </p> | |
| <hr/> | |
| <h2>Statements</h2> | |
| <p> | |
| Statements control execution. | |
| </p> | |
| <pre class="grammar"> | |
| Statement = | |
| Declaration | EmptyStmt | LabeledStmt | | |
| SimpleStmt | GoStmt | ReturnStmt | BreakStmt | ContinueStmt | GotoStmt | | |
| FallthroughStmt | Block | IfStmt | SwitchStmt | SelectStmt | ForStmt | | |
| DeferStmt . | |
| SimpleStmt = ExpressionStmt | IncDecStmt | Assignment | SimpleVarDecl . | |
| StatementList = Statement { Separator Statement } . | |
| Separator = [ ";" ] | |
| </pre> | |
| <p> | |
| Elements of a list of statements are separated by semicolons, | |
| which may be omitted only if the previous statement: | |
| </p> | |
| <ul> | |
| <li>ends with the closing parenthesis ")" of a list of declarations | |
| (§Declarations and Scope); or</li> | |
| <li>ends with a closing brace "}" that is not part of an expression. | |
| </ul> | |
| <h3>Empty statements</h3> | |
| <p> | |
| The empty statement does nothing. | |
| </p> | |
| <pre class="grammar"> | |
| EmptyStmt = . | |
| </pre> | |
| <p> | |
| A statement list can always in effect be terminated with a semicolon by | |
| adding an empty statement. | |
| </p> | |
| <h3>Labeled statements</h3> | |
| <p> | |
| A labeled statement may be the target of a <code>goto</code>, | |
| <code>break</code> or <code>continue</code> statement. | |
| </p> | |
| <pre class="grammar"> | |
| LabeledStmt = Label ":" Statement . | |
| Label = identifier . | |
| </pre> | |
| <pre> | |
| Error: log.Fatal("error encountered") | |
| </pre> | |
| <h3>Expression statements</h3> | |
| <p> | |
| Function calls, method calls, and channel operations | |
| can appear in statement context. | |
| </p> | |
| <pre class="grammar"> | |
| ExpressionStmt = Expression . | |
| </pre> | |
| <pre> | |
| f(x+y) | |
| <-ch | |
| </pre> | |
| <h3>IncDec statements</h3> | |
| <p> | |
| The "++" and "--" statements increment or decrement their operands | |
| by the ideal numeric value 1. As with an assignment, the operand | |
| must be a variable, pointer indirection, field selector or index expression. | |
| </p> | |
| <pre class="grammar"> | |
| IncDecStmt = Expression ( "++" | "--" ) . | |
| </pre> | |
| <p> | |
| The following assignment statements (§Assignments) are semantically | |
| equivalent: | |
| </p> | |
| <pre class="grammar"> | |
| IncDec statement Assignment | |
| x++ x += 1 | |
| x-- x -= 1 | |
| </pre> | |
| <h3>Assignments</h3> | |
| <pre class="grammar"> | |
| Assignment = ExpressionList assign_op ExpressionList . | |
| assign_op = [ add_op | mul_op ] "=" . | |
| </pre> | |
| <p> | |
| Each left-hand side operand must be a variable, pointer indirection, | |
| field selector, or index expression. | |
| </p> | |
| <pre> | |
| x = 1 | |
| *p = f() | |
| a[i] = 23 | |
| k = <-ch | |
| i &^= 1<<n | |
| </pre> | |
| <p> | |
| An <i>assignment operation</i> <code>x</code> <i>op</i><code>=</code> | |
| <code>y</code> where <i>op</i> is a binary arithmetic operation is equivalent | |
| to <code>x</code> <code>=</code> <code>x</code> <i>op</i> | |
| <code>y</code> but evalutates <code>x</code> | |
| only once. The <i>op</i><code>=</code> construct is a single token. | |
| </p> | |
| <pre> | |
| a[i] <<= 2 | |
| </pre> | |
| <p> | |
| A tuple assignment assigns the individual elements of a multi-valued | |
| operation to a list of variables. There are two forms. In the | |
| first, the right hand operand is a single multi-valued expression | |
| such as a function evaluation or channel or map operation (§Channel | |
| operations, §Map operations) or a type assertion (§Type assertions). | |
| The number of operands on the left | |
| hand side must match the number of values. For instance, If | |
| <code>f</code> is a function returning two values, | |
| </p> | |
| <pre> | |
| x, y = f() | |
| </pre> | |
| <p> | |
| assigns the first value to <code>x</code> and the second to <code>y</code>. | |
| </p> | |
| <p> | |
| In the second form, the number of operands on the left must equal the number | |
| of expressions on the right, each of which must be single-valued. | |
| The expressions on the right are evaluated before assigning to | |
| any of the operands on the left, but otherwise the evaluation | |
| order is unspecified. | |
| </p> | |
| <pre> | |
| a, b = b, a // exchange a and b | |
| </pre> | |
| <p> | |
| In assignments, the type of each value must be assignment compatible | |
| (§Assignment compatibility) with the type of the | |
| operand to which it is assigned. | |
| </p> | |
| <h3>If statements</h3> | |
| <p> | |
| "If" statements specify the conditional execution of two branches | |
| according to the value of a boolean expression. If the expression | |
| evaluates to true, the "if" branch is executed, otherwise, if | |
| present, the "else" branch is executed. A missing condition | |
| is equivalent to <code>true</code>. | |
| </p> | |
| <pre class="grammar"> | |
| IfStmt = "if" [ [ SimpleStmt ] ";" ] [ Expression ] Block [ "else" Statement ] . | |
| </pre> | |
| <pre> | |
| if x > 0 { | |
| return true; | |
| } | |
| </pre> | |
| <p> | |
| An "if" statement may include a simple statement before the expression. | |
| The scope of any variables declared by that statement | |
| extends to the end of the "if" statement | |
| and the variables are initialized once before the statement is entered. | |
| </p> | |
| <pre> | |
| if x := f(); x < y { | |
| return x; | |
| } else if x > z { | |
| return z; | |
| } else { | |
| return y; | |
| } | |
| </pre> | |
| <h3>Switch statements</h3> | |
| <p> | |
| "Switch" statements provide multi-way execution. | |
| An expression or type specifier is compared to the "cases" | |
| inside the "switch" to determine which branch | |
| to execute. | |
| </p> | |
| <pre class="grammar"> | |
| SwitchStmt = ExprSwitchStmt | TypeSwitchStmt . | |
| </pre> | |
| <p> | |
| There are two forms: expression switches and type switches. | |
| In an expression switch, the cases contain expressions that are compared | |
| against the value of the switch expression. | |
| In a type switch, the cases contain types that are compared against the | |
| type of a specially annotated switch expression. | |
| </p> | |
| <h4>Expression switches</h4> | |
| <p> | |
| In an expression switch, | |
| the switch expression is evaluated and | |
| the case expressions, which need not be constants, | |
| are evaluated top-to-bottom; the first one that equals the | |
| switch expression | |
| triggers execution of the statements of the associated case; | |
| the other cases are skipped. | |
| If no case matches and there is a "default" case, | |
| its statements are executed. | |
| There can be at most one default case and it may appear anywhere in the | |
| "switch" statement. | |
| A missing expression is equivalent to | |
| the expression <code>true</code>. | |
| </p> | |
| <pre class="grammar"> | |
| ExprSwitchStmt = "switch" [ [ SimpleStmt ] ";" ] [ Expression ] "{" { ExprCaseClause } "}" . | |
| ExprCaseClause = ExprSwitchCase ":" [ StatementList ] . | |
| ExprSwitchCase = "case" ExpressionList | "default" . | |
| </pre> | |
| <p> | |
| In a case or default clause, | |
| the last statement only may be a "fallthrough" statement | |
| (§Fallthrough statement) to | |
| indicate that control should flow from the end of this clause to | |
| the first statement of the next clause. | |
| Otherwise control flows to the end of the "switch" statement. | |
| </p> | |
| <p> | |
| Each case clause acts as a block for scoping purposes | |
| (§Declarations and scope rules). | |
| </p> | |
| <p> | |
| A "switch" statement may include a simple statement before the | |
| expression. | |
| The scope of any variables declared by that statement | |
| extends to the end of the "switch" statement | |
| and the variables are initialized once before the statement is entered. | |
| </p> | |
| <pre> | |
| switch tag { | |
| default: s3() | |
| case 0, 1, 2, 3: s1() | |
| case 4, 5, 6, 7: s2() | |
| } | |
| switch x := f(); { | |
| case x < 0: return -x | |
| default: return x | |
| } | |
| switch { // missing expression means "true" | |
| case x < y: f1(); | |
| case x < z: f2(); | |
| case x == 4: f3(); | |
| } | |
| </pre> | |
| <h4>Type switches</h4> | |
| <p> | |
| A type switch compares types rather than values. It is otherwise similar | |
| to an expression switch. It is introduced by special | |
| notation in the form of a simple declaration whose right hand side | |
| has the form of a type assertion (§Type assertions) | |
| using the reserved word <code>type</code> rather than an actual type. | |
| Cases then match literal types against the dynamic type of the expression | |
| in the type assertion. | |
| </p> | |
| <pre class="grammar"> | |
| TypeSwitchStmt = "switch" [ [ SimpleStmt ] ";" ] TypeSwitchGuard "{" { TypeCaseClause } "}" . | |
| TypeSwitchGuard = identifier ":=" Expression "." "(" "type" ")" . | |
| TypeCaseClause = TypeSwitchCase ":" [ StatementList ] . | |
| TypeSwitchCase = "case" ( type | "nil" ) | "default" . | |
| </pre> | |
| <p> | |
| If the interface value equals <code>nil</code>, | |
| only an explict <code>nil</code> case or "default" | |
| case will execute. | |
| </p> | |
| <p> | |
| Given a function <code>f</code> | |
| that returns a value of interface type, | |
| the following type switch: | |
| </p> | |
| <pre> | |
| switch i := f().(type) { | |
| case nil: | |
| printString("f() returns nil"); | |
| case int: | |
| printInt(i); // i is an int | |
| case float: | |
| printFloat(i); // i is a float | |
| case func(int) float: | |
| printFunction(i); // i is a function | |
| default: | |
| printString("don't know the type"); | |
| } | |
| </pre> | |
| <p> | |
| could be rewritten: | |
| </p> | |
| <pre> | |
| v := f(); | |
| if v == nil { | |
| printString("f() returns nil"); | |
| } else if i, is_int := v.(int); is_int { | |
| printInt(i); // i is an int | |
| } else if i, is_float := v.(float); is_float { | |
| printFloat(i); // i is a float | |
| } else if i, is_func := v.(func(int) float); is_func { | |
| printFunction(i); // i is a function | |
| } else { | |
| printString("don't know the type"); | |
| } | |
| </pre> | |
| <p> | |
| In a type switch, the guard is mandatory, | |
| there can be only one type per "case", and | |
| the "fallthrough" statement is not allowed. | |
| </p> | |
| <h3>For statements</h3> | |
| <p> | |
| A "for" statement specifies repeated execution of a block. The iteration is | |
| controlled by a condition, a "for" clause, or a "range" clause. | |
| </p> | |
| <pre class="grammar"> | |
| ForStmt = "for" [ Condition | ForClause | RangeClause ] Block . | |
| Condition = Expression . | |
| </pre> | |
| <p> | |
| In its simplest form, a "for" statement specifies the repeated execution of | |
| a block as long as a boolean condition evaluates to true. | |
| The condition is evaluated before each iteration. | |
| If the condition is absent, it is equivalent to <code>true</code>. | |
| </p> | |
| <pre> | |
| for a < b { | |
| a *= 2 | |
| } | |
| </pre> | |
| <p> | |
| A "for" statement with a "for" clause is also controlled by its condition, but | |
| additionally it may specify an <i>init</i> | |
| and a <i>post</i> statement, such as an assignment, | |
| an increment or decrement statement. The init statement (but not the post | |
| statement) may also be a short variable declaration; the scope of the variables | |
| it declares ends at the end of the statement | |
| (§Declarations and scope rules). | |
| </p> | |
| <pre class="grammar"> | |
| ForClause = [ InitStmt ] ";" [ Condition ] ";" [ PostStmt ] . | |
| InitStmt = SimpleStmt . | |
| PostStmt = SimpleStmt . | |
| </pre> | |
| <pre> | |
| for i := 0; i < 10; i++ { | |
| f(i) | |
| } | |
| </pre> | |
| <p> | |
| If non-empty, the init statement is executed once before evaluating the | |
| condition for the first iteration; | |
| the post statement is executed after each execution of the block (and | |
| only if the block was executed). | |
| Any element of the "for" clause may be empty but the semicolons are | |
| required unless there is only a condition. | |
| If the condition is absent, it is equivalent to <code>true</code>. | |
| </p> | |
| <pre> | |
| for ; cond ; { S() } is the same as for cond { S() } | |
| for true { S() } is the same as for { S() } | |
| </pre> | |
| <p> | |
| A "for" statement with a "range" clause | |
| iterates through all entries of an array, slice or map. | |
| For each entry it first assigns the current index or key to an iteration | |
| variable - or the current (index, element) or (key, value) pair to a pair | |
| of iteration variables - and then executes the block. | |
| </p> | |
| <pre class="grammar"> | |
| RangeClause = IdentifierList ( "=" | ":=" ) "range" Expression . | |
| </pre> | |
| <p> | |
| The type of the right-hand expression in the "range" clause must be an array, | |
| slice or map, or a pointer to an array, slice or map; | |
| or it may be a channel. | |
| If it is an array, slice or map, | |
| the identifier list must contain one or two identifiers denoting the | |
| iteration variables. On each iteration, | |
| the first variable is set to the array or slice index or | |
| map key, and the second variable, if present, is set to the corresponding | |
| array element or map value. | |
| The types of the array or slice index (always <code>int</code>) | |
| and element, or of the map key and value respectively, | |
| must be assignment compatible to the iteration variables. | |
| </p> | |
| <p> | |
| For channels, the identifier list must contain one identifier. | |
| The iteration recieves values sent on the channel until the channel is closed; | |
| it does not process the zero value sent before the channel is closed. | |
| </p> | |
| <p> | |
| The iteration variables may be declared by the "range" clause (":="), in which | |
| case their scope ends at the end of the "for" statement (§Declarations and | |
| scope rules). In this case their types are set to | |
| <code>int</code> and the array element type, or the map key and value types, respectively. | |
| If the iteration variables are declared outside the "for" statement, | |
| after execution their values will be those of the last iteration. | |
| </p> | |
| <pre> | |
| var a [10]string; | |
| m := map[string]int{"mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6}; | |
| for i, s := range a { | |
| // type of i is int | |
| // type of s is string | |
| // s == a[i] | |
| g(i, s) | |
| } | |
| var key string; | |
| var val interface {}; // value type of m is assignment-compatible to val | |
| for key, value = range m { | |
| h(key, value) | |
| } | |
| // key == last map key encountered in iteration | |
| // val == map[key] | |
| </pre> | |
| <p> | |
| If map entries that have not yet been processed are deleted during iteration, | |
| they will not be processed. If map entries are inserted during iteration, the | |
| behavior is implementation-dependent, but each entry will be processed at most once. | |
| </p> | |
| <h3>Go statements</h3> | |
| <p> | |
| A "go" statement starts the execution of a function or method call | |
| as an independent concurrent thread of control, or <i>goroutine</i>, | |
| within the same address space. | |
| </p> | |
| <pre class="grammar"> | |
| GoStmt = "go" Expression . | |
| </pre> | |
| <p> | |
| The expression must be a call, and | |
| unlike with a regular call, program execution does not wait | |
| for the invoked function to complete. | |
| </p> | |
| <pre> | |
| go Server() | |
| go func(ch chan <- bool) { for { sleep(10); ch <- true; }} (c) | |
| </pre> | |
| <h3>Select statements</h3> | |
| <p> | |
| A "select" statement chooses which of a set of possible communications | |
| will proceed. It looks similar to a "switch" statement but with the | |
| cases all referring to communication operations. | |
| </p> | |
| <pre class="grammar"> | |
| SelectStmt = "select" "{" { CommClause } "}" . | |
| CommClause = CommCase ":" StatementList . | |
| CommCase = "case" ( SendExpr | RecvExpr) | "default" . | |
| SendExpr = Expression "<-" Expression . | |
| RecvExpr = [ Expression ( "=" | ":=" ) ] "<-" Expression . | |
| </pre> | |
| <p> | |
| Each communication clause acts as a block for the purpose of scoping | |
| (§Declarations and scope rules). | |
| </p> | |
| <p> | |
| For all the send and receive expressions in the "select" | |
| statement, the channel expression is evaluated. Any expressions | |
| that appear on the right hand side of send expressions are also | |
| evaluated. If any of the resulting channels can proceed, one is | |
| chosen and the corresponding communication and statements are | |
| evaluated. Otherwise, if there is a default case, that executes; | |
| if not, the statement blocks until one of the communications can | |
| complete. The channels and send expressions are not re-evaluated. | |
| A channel pointer may be <code>nil</code>, | |
| which is equivalent to that case not | |
| being present in the select statement | |
| except, if a send, its expression is still evaluated. | |
| </p> | |
| <p> | |
| Since all the channels and send expressions are evaluated, any side | |
| effects in that evaluation will occur for all the communications | |
| in the "select" statement. | |
| </p> | |
| <p> | |
| If multiple cases can proceed, a uniform fair choice is made to decide | |
| which single communication will execute. | |
| <p> | |
| The receive case may declare a new variable using a short variable declaration | |
| (§Short variable declarations). | |
| The scope of such variables continues to the end of the | |
| respective case's statements. | |
| </p> | |
| <pre> | |
| var c, c1, c2 chan int; | |
| var i1, i2 int; | |
| select { | |
| case i1 = <-c1: | |
| print("received ", i1, " from c1\n"); | |
| case c2 <- i2: | |
| print("sent ", i2, " to c2\n"); | |
| default: | |
| print("no communication\n"); | |
| } | |
| for { // send random sequence of bits to c | |
| select { | |
| case c <- 0: // note: no statement, no fallthrough, no folding of cases | |
| case c <- 1: | |
| } | |
| } | |
| </pre> | |
| <font color=red> | |
| TODO: Make semantics more precise. | |
| </font> | |
| <h3>Return statements</h3> | |
| <p> | |
| A "return" statement terminates execution of the containing function | |
| and optionally provides a result value or values to the caller. | |
| </p> | |
| <pre class="grammar"> | |
| ReturnStmt = "return" [ ExpressionList ] . | |
| </pre> | |
| <pre> | |
| func procedure() { | |
| return | |
| } | |
| </pre> | |
| <p> | |
| There are two ways to return values from a function with a result | |
| type. The first is to explicitly list the return value or values | |
| in the "return" statement. | |
| Normally, the expressions | |
| must be single-valued and assignment-compatible to the elements of | |
| the result type of the function. | |
| </p> | |
| <pre> | |
| func simple_f() int { | |
| return 2 | |
| } | |
| func complex_f1() (re float, im float) { | |
| return -7.0, -4.0 | |
| } | |
| </pre> | |
| <p> | |
| However, if the expression list in the "return" statement is a single call | |
| to a multi-valued function, the values returned from the called function | |
| will be returned from this one. The result types of the current function | |
| and the called function must match. | |
| </p> | |
| <pre> | |
| func complex_f2() (re float, im float) { | |
| return complex_f1() | |
| } | |
| </pre> | |
| <p> | |
| The second way to return values is to use the elements of the | |
| result list of the function as variables. When the function begins | |
| execution, these variables are initialized to the zero values for | |
| their type (§The zero value). The function can assign them as | |
| necessary; if the "return" provides no values, those of the variables | |
| will be returned to the caller. | |
| </p> | |
| <pre> | |
| func complex_f3() (re float, im float) { | |
| re = 7.0; | |
| im = 4.0; | |
| return; | |
| } | |
| </pre> | |
| <p> | |
| TODO: Define when return is required. | |
| </p> | |
| <h3>Break statements</h3> | |
| <p> | |
| A "break" statement terminates execution of the innermost | |
| "for", "switch" or "select" statement. | |
| </p> | |
| <pre class="grammar"> | |
| BreakStmt = "break" [ Label ]. | |
| </pre> | |
| <p> | |
| If there is a label, it must be that of an enclosing | |
| "for", "switch" or "select" statement, and that is the one whose execution | |
| terminates | |
| (§For statements, §Switch statements, §Select statements). | |
| </p> | |
| <pre> | |
| L: for i < n { | |
| switch i { | |
| case 5: break L | |
| } | |
| } | |
| </pre> | |
| <h3>Continue statements</h3> | |
| <p> | |
| A "continue" statement begins the next iteration of the | |
| innermost "for" loop at the post statement (§For statements). | |
| </p> | |
| <pre class="grammar"> | |
| ContinueStmt = "continue" [ Label ]. | |
| </pre> | |
| <p> | |
| The optional label is analogous to that of a "break" statement. | |
| </p> | |
| <h3>Goto statements</h3> | |
| <p> | |
| A "goto" statement transfers control to the statement with the corresponding label. | |
| </p> | |
| <pre class="grammar"> | |
| GotoStmt = "goto" Label . | |
| </pre> | |
| <pre> | |
| goto Error | |
| </pre> | |
| <p> | |
| Executing the "goto" statement must not cause any variables to come into | |
| scope that were not already in scope at the point of the goto. For | |
| instance, this example: | |
| </p> | |
| <pre> | |
| goto L; // BAD | |
| v := 3; | |
| L: | |
| </pre> | |
| <p> | |
| is erroneous because the jump to label <code>L</code> skips | |
| the creation of <code>v</code>. | |
| (TODO: Eliminate in favor of used and not set errors?) | |
| </p> | |
| <h3>Fallthrough statements</h3> | |
| <p> | |
| A "fallthrough" statement transfers control to the first statement of the | |
| next case clause in a expression "switch" statement (§Expression switches). It may | |
| be used only as the final non-empty statement in a case or default clause in an | |
| expression "switch" statement. | |
| </p> | |
| <pre class="grammar"> | |
| FallthroughStmt = "fallthrough" . | |
| </pre> | |
| <h3>Defer statements</h3> | |
| <p> | |
| A "defer" statement invokes a function whose execution is deferred to the moment | |
| the surrounding function returns. | |
| </p> | |
| <pre class="grammar"> | |
| DeferStmt = "defer" Expression . | |
| </pre> | |
| <p> | |
| The expression must be a function or method call. | |
| Each time the "defer" statement | |
| executes, the parameters to the function call are evaluated and saved anew but the | |
| function is not invoked. Immediately before the innermost function surrounding | |
| the "defer" statement returns, but after its return value (if any) is evaluated, | |
| each deferred function is executed with its saved parameters. Deferred functions | |
| are executed in LIFO order. | |
| </p> | |
| <pre> | |
| lock(l); | |
| defer unlock(l); // unlocking happens before surrounding function returns | |
| // prints 3 2 1 0 before surrounding function returns | |
| for i := 0; i <= 3; i++ { | |
| defer fmt.Print(i); | |
| } | |
| </pre> | |
| <hr/> | |
| <h2>Predeclared functions</h2> | |
| <ul> | |
| <li>cap | |
| <li>close | |
| <li>closed | |
| <li>len | |
| <li>make | |
| <li>new | |
| <li>panic | |
| <li>panicln | |
| <li>print | |
| <li>println | |
| </ul> | |
| <h3>Length and capacity</h3> | |
| <pre class="grammar"> | |
| Call Argument type Result | |
| len(s) string, *string string length (in bytes) | |
| [n]T, *[n]T array length (== n) | |
| []T, *[]T slice length | |
| map[K]T, *map[K]T map length | |
| chan T number of elements in channel buffer | |
| cap(s) []T, *[]T capacity of s | |
| map[K]T, *map[K]T capacity of s | |
| chan T channel buffer capacity | |
| </pre> | |
| <p> | |
| The type of the result is always <code>int</code> and the | |
| implementation guarantees that | |
| the result always fits into an <code>int</code>. | |
| <p> | |
| The capacity of a slice or map is the number of elements for which there is | |
| space allocated in the underlying array (for a slice) or map. For a slice | |
| <code>s</code>, at any time the following relationship holds: | |
| <pre> | |
| 0 <= len(s) <= cap(s) | |
| </pre> | |
| <h3>Conversions</h3> | |
| <p> | |
| Conversions look like function calls of the form | |
| </p> | |
| <pre class="grammar"> | |
| T(value) | |
| </pre> | |
| <p> | |
| where <code>T</code> is a type | |
| and <code>value</code> is an expression | |
| that can be converted to a value | |
| of result type <code>T</code>. | |
| <p> | |
| The following conversion rules apply: | |
| </p> | |
| <ul> | |
| <li> | |
| 1) Between equal types. The conversion always succeeds. | |
| </li> | |
| <li> | |
| 2) Between integer types. If the value is a signed quantity, it is | |
| sign extended to implicit infinite precision; otherwise it is zero | |
| extended. It is then truncated to fit in the result type size. | |
| For example, <code>uint32(int8(0xFF))</code> is <code>0xFFFFFFFF</code>. | |
| The conversion always yields a valid value; there is no signal for overflow. | |
| </li> | |
| <li> | |
| 3) Between integer and floating point types, or between floating point | |
| types. To avoid overdefining the properties of the conversion, for | |
| now it is defined as a ``best effort'' conversion. The conversion | |
| always succeeds but the value may be a NaN or other problematic | |
| result. <font color=red>TODO: clarify?</font> | |
| </li> | |
| <li> | |
| 4) Strings permit two special conversions. | |
| </li> | |
| <li> | |
| 4a) Converting an integer value yields a string containing the UTF-8 | |
| representation of the integer. | |
| (TODO: this one could be done just as well by a library.) | |
| <pre> | |
| string(0x65e5) // "\u65e5" | |
| </pre> | |
| </li> | |
| <li> | |
| 4b) Converting an array or slice of bytes yields a string whose successive | |
| bytes are those of the array/slice. | |
| <pre> | |
| string([]byte{'h', 'e', 'l', 'l', 'o'}) // "hello" | |
| </pre> | |
| </li> | |
| </ul> | |
| <p> | |
| There is no linguistic mechanism to convert between pointers and integers. | |
| The <code>unsafe</code> package | |
| implements this functionality under | |
| restricted circumstances (§Package <code>unsafe</code>). | |
| </p> | |
| <h3>Allocation</h3> | |
| <p> | |
| The built-in function <code>new</code> takes a type <code>T</code> and | |
| returns a value of type <code>*T</code>. | |
| The memory is initialized as described in the section on initial values | |
| (§The zero value). | |
| </p> | |
| <pre> | |
| new(T) | |
| </pre> | |
| <p> | |
| For instance | |
| </p> | |
| <pre> | |
| type S struct { a int; b float } | |
| new(S) | |
| </pre> | |
| <p> | |
| dynamically allocates memory for a variable of type <code>S</code>, | |
| initializes it (<code>a=0</code>, <code>b=0.0</code>), | |
| and returns a value of type <code>*S</code> containing the address | |
| of the memory. | |
| </p> | |
| <h3>Making slices, maps and channels</h3> | |
| <p> | |
| Slices, maps and channels are reference types that do not require the | |
| extra indirection of an allocation with <code>new</code>. | |
| The built-in function <code>make</code> takes a type <code>T</code>, | |
| which must be a slice, map or channel type, | |
| optionally followed by a type-specific list of expressions. | |
| It returns a value of type <code>T</code> (not <code>*T</code>). | |
| The memory is initialized as described in the section on initial values | |
| (§The zero value). | |
| </p> | |
| <pre> | |
| make(T [, optional list of expressions]) | |
| </pre> | |
| <p> | |
| For instance | |
| </p> | |
| <pre> | |
| make(map[string] int) | |
| </pre> | |
| <p> | |
| creates a new map value and initializes it to an empty map. | |
| </p> | |
| <p> | |
| The parameters affect sizes for allocating slices, maps, and | |
| buffered channels: | |
| </p> | |
| <pre> | |
| s := make([]int, 10, 100); # slice with len(s) == 10, cap(s) == 100 | |
| c := make(chan int, 10); # channel with a buffer size of 10 | |
| m := make(map[string] int, 100); # map with initial space for 100 elements | |
| </pre> | |
| <hr/> | |
| <h2>Packages</h2> | |
| <p> | |
| Go programs are constructed by linking together <i>packages</i>. | |
| A package is in turn constructed from one or more source files that | |
| together provide access to a set of types, constants, functions, | |
| and variables. Those elements may be <i>imported</i> and used in | |
| another package. | |
| </p> | |
| <h3>Source file organization</h3> | |
| <p> | |
| Each source file consists of a package clause defining the package | |
| to which it belongs, followed by a possibly empty set of import | |
| declarations that declare packages whose contents it wishes to use, | |
| followed by a possibly empty set of declarations of functions, | |
| types, variables, and constants. The source text following the | |
| package clause acts as a block for scoping (§Declarations and scope | |
| rules). | |
| </p> | |
| <pre class="grammar"> | |
| SourceFile = PackageClause { ImportDecl [ ";" ] } { Declaration [ ";" ] } . | |
| </pre> | |
| <h3>Package clause</h3> | |
| <p> | |
| A package clause begins each source file and defines the package | |
| to which the file belongs. | |
| </p> | |
| <pre class="grammar"> | |
| PackageClause = "package" PackageName . | |
| </pre> | |
| <pre> | |
| package math | |
| </pre> | |
| <p> | |
| A set of files sharing the same PackageName form the implementation of a package. | |
| An implementation may require that all source files for a package inhabit the same directory. | |
| </p> | |
| <h3>Import</h3> | |
| <p> | |
| A source file gains access to exported identifiers (§Exported | |
| identifiers) from another package through an import declaration. | |
| In the general form, an import declaration provides an identifier | |
| that code in the source file may use to access the imported package's | |
| contents and a file name referring to the (compiled) implementation of | |
| the package. The file name may be relative to a repository of | |
| installed packages. | |
| </p> | |
| <pre class="grammar"> | |
| ImportDecl = "import" ( ImportSpec | "(" [ ImportSpecList ] ")" ) . | |
| ImportSpecList = ImportSpec { ";" ImportSpec } [ ";" ] . | |
| ImportSpec = [ "." | PackageName ] PackageFileName . | |
| PackageFileName = StringLit . | |
| </pre> | |
| <p> | |
| After an import, in the usual case an exported name <i>N</i> from the imported | |
| package <i>P</i> may be accessed by the qualified identifier | |
| <i>P</i><code>.</code><i>N</i> (§Qualified identifiers). The actual | |
| name <i>P</i> depends on the form of the import declaration. If | |
| an explicit package name <code>p1</code> is provided, the qualified | |
| identifer will have the form <code>p1.</code><i>N</i>. If no name | |
| is provided in the import declaration, <i>P</i> will be the package | |
| name declared within the source files of the imported package. | |
| Finally, if the import declaration uses an explicit period | |
| (<code>.</code>) for the package name, <i>N</i> will appear | |
| in the package-level scope of the current file and the qualified name is | |
| unnecessary and erroneous. In this form, it is an error if the import introduces | |
| a name conflict. | |
| </p> | |
| <p> | |
| In this table, assume we have compiled a package named | |
| <code>math</code>, which exports function <code>Sin</code>, and | |
| installed the compiled package in file | |
| <code>"lib/math"</code>. | |
| </p> | |
| <pre class="grammar"> | |
| Import syntax Local name of Sin | |
| import M "lib/math" M.Sin | |
| import "lib/math" math.Sin | |
| import . "lib/math" Sin | |
| </pre> | |
| <h3>Multi-file packages</h3> | |
| <p> | |
| If a package is constructed from multiple source files, all names | |
| at package-level scope, not just exported names, are visible to all the | |
| files in the package. An import declaration is still necessary to | |
| declare intention to use the names, | |
| but the imported names do not need a qualified identifer to be | |
| accessed. | |
| </p> | |
| <p> | |
| The compilation of a multi-file package may require | |
| that the files be compiled and installed in an order that satisfies | |
| the resolution of names imported within the package. | |
| </p> | |
| <p> | |
| If source file <code>math1.go</code> contains | |
| </p> | |
| <pre> | |
| package math | |
| const twoPi = 6.283185307179586 | |
| function Sin(x float) float { return ... } | |
| </pre> | |
| <p> | |
| and file <code>"math2.go"</code> begins | |
| </p> | |
| <pre> | |
| package math | |
| import "lib/math" | |
| </pre> | |
| <p> | |
| then, provided <code>"math1.go"</code> is compiled first and | |
| installed in <code>"lib/math"</code>, <code>math2.go</code> | |
| may refer directly to <code>Sin</code> and <code>twoPi</code> | |
| without a qualified identifier. | |
| </p> | |
| <h3>An example package</h3> | |
| <p> | |
| Here is a complete Go package that implements a concurrent prime sieve. | |
| </p> | |
| <pre> | |
| package main | |
| import "fmt" | |
| // Send the sequence 2, 3, 4, ... to channel 'ch'. | |
| func generate(ch chan <- int) { | |
| for i := 2; ; i++ { | |
| ch <- i // Send 'i' to channel 'ch'. | |
| } | |
| } | |
| // Copy the values from channel 'in' to channel 'out', | |
| // removing those divisible by 'prime'. | |
| func filter(src chan <- int, dst <-chan int, prime int) { | |
| for i := range src { // Loop over values received from 'src'. | |
| if i % prime != 0 { | |
| dst <- i // Send 'i' to channel 'dst'. | |
| } | |
| } | |
| } | |
| // The prime sieve: Daisy-chain filter processes together. | |
| func sieve() { | |
| ch := make(chan int); // Create a new channel. | |
| go generate(ch); // Start generate() as a subprocess. | |
| for { | |
| prime := <-ch; | |
| fmt.Print(prime, "\n"); | |
| ch1 := make(chan int); | |
| go filter(ch, ch1, prime); | |
| ch = ch1 | |
| } | |
| } | |
| func main() { | |
| sieve() | |
| } | |
| </pre> | |
| <hr/> | |
| <h2>Program initialization and execution</h2> | |
| <h3>The zero value</h3> | |
| <p> | |
| When memory is allocated to store a value, either through a declaration | |
| or <code>new()</code>, and no explicit initialization is provided, the memory is | |
| given a default initialization. Each element of such a value is | |
| set to the zero value for its type: <code>false</code> for booleans, | |
| <code>0</code> for integers, <code>0.0</code> for floats, <code>""</code> | |
| for strings, and <code>nil</code> for pointers and interfaces. | |
| This initialization is done recursively, so for instance each element of an | |
| array of structs will have its fields zeroed if no value is specified. | |
| </p> | |
| <p> | |
| These two simple declarations are equivalent: | |
| </p> | |
| <pre> | |
| var i int; | |
| var i int = 0; | |
| </pre> | |
| <p> | |
| After | |
| </p> | |
| <pre> | |
| type T struct { i int; f float; next *T }; | |
| t := new(T); | |
| </pre> | |
| <p> | |
| the following holds: | |
| </p> | |
| <pre> | |
| t.i == 0 | |
| t.f == 0.0 | |
| t.next == nil | |
| </pre> | |
| <p> | |
| The same would also be true after | |
| </p> | |
| <pre> | |
| var t T | |
| </pre> | |
| <h3>Program execution</h3> | |
| <p> | |
| A package with no imports is initialized by assigning initial values to | |
| all its package-level variables in declaration order and then calling any | |
| package-level function with the name and signature of | |
| </p> | |
| <pre> | |
| func init() | |
| </pre> | |
| <p> | |
| defined in its source. Since a package may contain more | |
| than one source file, there may be more than one | |
| <code>init()</code> function in a package, but | |
| only one per source file. | |
| </p> | |
| <p> | |
| Initialization code may contain "go" statements, but the functions | |
| they invoke do not begin execution until initialization of the entire | |
| program is complete. Therefore, all initialization code is run in a single | |
| goroutine. | |
| </p> | |
| <p> | |
| An <code>init()</code> function cannot be referred to from anywhere | |
| in a program. In particular, <code>init()</code> cannot be called explicitly, | |
| nor can a pointer to <code>init</code> be assigned to a function variable. | |
| </p> | |
| <p> | |
| If a package has imports, the imported packages are initialized | |
| before initializing the package itself. If multiple packages import | |
| a package <code>P</code>, <code>P</code> will be initialized only once. | |
| </p> | |
| <p> | |
| The importing of packages, by construction, guarantees that there can | |
| be no cyclic dependencies in initialization. | |
| </p> | |
| <p> | |
| A complete program, possibly created by linking multiple packages, | |
| must have one package called <code>main</code>, with a function | |
| </p> | |
| <pre> | |
| func main() { ... } | |
| </pre> | |
| <p> | |
| defined. | |
| The function <code>main.main()</code> takes no arguments and returns no value. | |
| </p> | |
| <p> | |
| Program execution begins by initializing the <code>main</code> package and then | |
| invoking <code>main.main()</code>. | |
| </p> | |
| <p> | |
| When <code>main.main()</code> returns, the program exits. | |
| </p> | |
| <p> | |
| Implementation restriction: The compiler assumes package <code>main</code> | |
| is created by a single source file and that it is not imported by any other package. | |
| </p> | |
| <hr/> | |
| <h2>System considerations</h2> | |
| <h3>Package <code>unsafe</code></h3> | |
| <p> | |
| The built-in package <code>unsafe</code>, known to the compiler, | |
| provides facilities for low-level programming including operations | |
| that violate the type system. A package using <code>unsafe</code> | |
| must be vetted manually for type safety. The package provides the | |
| following interface: | |
| </p> | |
| <pre class="grammar"> | |
| package unsafe | |
| const Maxalign int | |
| type Pointer *any // "any" is shorthand for any Go type; it is not a real type. | |
| func Alignof(variable any) int | |
| func Offsetof(selector any) int | |
| func Sizeof(variable any) int | |
| </pre> | |
| <p> | |
| Any pointer or value of type <code>uintptr</code> can be converted into | |
| a <code>Pointer</code> and vice versa. | |
| </p> | |
| <p> | |
| The function <code>Sizeof</code> takes an expression denoting a | |
| variable of any (complete) type and returns the size of the variable in bytes. | |
| </p> | |
| <p> | |
| The function <code>Offsetof</code> takes a selector (§Selectors) denoting a struct | |
| field of any type and returns the field offset in bytes relative to the | |
| struct's address. For a struct <code>s</code> with field <code>f</code>: | |
| </p> | |
| <pre> | |
| uintptr(unsafe.Pointer(&s)) + uintptr(unsafe.Offsetof(s.f)) == uintptr(unsafe.Pointer(&s.f)) | |
| </pre> | |
| <p> | |
| Computer architectures may require memory addresses to be <i>aligned</i>; | |
| that is, for addresses of a variable to be a multiple of a factor, | |
| the variable's type's <i>alignment</i>. The function <code>Alignof</code> | |
| takes an expression denoting a variable of any type and returns the | |
| alignment of the (type of the) variable in bytes. For a variable | |
| <code>x</code>: | |
| </p> | |
| <pre> | |
| uintptr(unsafe.Pointer(&x)) % uintptr(unsafe.Alignof(x)) == 0 | |
| </pre> | |
| <p> | |
| The maximum alignment is given by the constant <code>Maxalign</code>. | |
| It usually corresponds to the value of <code>Sizeof(x)</code> for | |
| a variable <code>x</code> of the largest numeric type (8 for a | |
| <code>float64</code>), but may | |
| be smaller on systems with weaker alignment restrictions. | |
| </p> | |
| <p> | |
| Calls to <code>Alignof</code>, <code>Offsetof</code>, and | |
| <code>Sizeof</code> are constant expressions of type <code>int</code>. | |
| </p> | |
| <h3>Size and alignment guarantees</h3> | |
| For the numeric types (§Numeric types), the following sizes are guaranteed: | |
| <pre class="grammar"> | |
| type size in bytes | |
| byte, uint8, int8 1 | |
| uint16, int16 2 | |
| uint32, int32, float32 4 | |
| uint64, int64, float64 8 | |
| </pre> | |
| <p> | |
| The following minimal alignment properties are guaranteed: | |
| </p> | |
| <ol> | |
| <li>For a variable <code>x</code> of any type: <code>1 <= unsafe.Alignof(x) <= unsafe.Maxalign</code>. | |
| <li>For a variable <code>x</code> of numeric type: <code>unsafe.Alignof(x)</code> is the smaller | |
| of <code>unsafe.Sizeof(x)</code> and <code>unsafe.Maxalign</code>, but at least 1. | |
| <li>For a variable <code>x</code> of struct type: <code>unsafe.Alignof(x)</code> is the largest of | |
| all the values <code>unsafe.Alignof(x.f)</code> for each field <code>f</code> of x, but at least 1. | |
| <li>For a variable <code>x</code> of array type: <code>unsafe.Alignof(x)</code> is the same as | |
| <code>unsafe.Alignof(x[0])</code>, but at least 1. | |
| </ol> | |
| <hr/> | |
| <h2><font color=red>Differences between this doc and implementation - TODO</font></h2> | |
| <p> | |
| <font color=red> | |
| Implementation accepts only ASCII digits for digits; doc says Unicode. | |
| <br/> | |
| Implementation does not honor the restriction on goto statements and targets (no intervening declarations). | |
| <br/> | |
| cap() does not work on maps or chans. | |
| <br/> | |
| len() does not work on chans. | |
| </font> | |
| </p> | |
| </div> | |
| </body> | |
| </html> |