| |
| |
| <!-- |
| Biggest open issues: |
| [ ] General iterators |
| [ ] Conversions: |
| - current situation is messy |
| - 2 (3?) different notations for the same thing |
| - unclear when a type guard is needed |
| - unclear where conversions can be applied |
| - for type T int; can we say T(3.0) ? |
| - do we need channel conversion (channel direction) |
| [ ] 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: |
| [ ] there is some funny-ness regarding ';' and empty statements and label decls |
| [ ] 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?) |
| [ ] cleanup convert() vs T() vs x.(T) - convert() should go away? |
| [ ] 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. |
| |
| |
| 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: |
| [ ] need for type switch? (or use type guard with ok in tuple assignment?) |
| [ ] Is . import implemented / do we still need it? |
| [ ] 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? |
| |
| |
| 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] type switch or some form of type test needed - duplicate entry |
| [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 parseable 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) |
| |
| Timeline (9/5/08): |
| - threads: 1 month |
| - reflection code: 2 months |
| - proto buf support: 3 months |
| - GC: 6 months |
| - debugger |
| - Jan 1, 2009: enough support to write interesting programs |
| --> |
| |
| <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 <tt>""</tt> (the double quote symbol is written as |
| <tt>'"'</tt>). |
| </p> |
| |
| <p> |
| The form <tt>"a ... b"</tt> represents the set of characters from |
| <tt>a</tt> through <tt>b</tt> as alternatives. |
| </p> |
| |
| <p> |
| Where possible, recursive productions are used to express evaluation order |
| and operator precedence syntactically. |
| </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 <tt>_</tt> (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 <tt>//</tt> and continues through the next newline. The |
| second starts at the character sequence <tt>/*</tt> and continues |
| through the character sequence <tt>*/</tt>. 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> |
| <p> |
| Exported identifiers (§Exported identifiers) start with a <tt>capital_letter</tt>. |
| <br> |
| <font color=red>TODO: This sentence feels out of place.</font> |
| </p> |
| <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: <tt>0</tt> for octal, <tt>0x</tt> or |
| <tt>0X</tt> for hexadecimal. In hexadecimal literals, letters |
| <tt>a-f</tt> and <tt>A-F</tt> 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 <tt>e</TT> or <tt>E</tt> |
| 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 a large internal representation of such numbers. |
| <br> |
| <font color=red>TODO: This is too vague. It used to say "sufficiently" |
| but that doesn't help. Define a minimum?</font> |
| </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 <tt>'a'</tt> holds a single byte representing |
| a literal <tt>a</tt>, Unicode U+0061, value <tt>0x61</tt>, while |
| <tt>'ä'</tt> holds two bytes (<tt>0xc3</tt> <tt>0xa4</tt>) representing |
| a literal <tt>a</tt>-dieresis, U+00E4, value <tt>0xe4</tt>. |
| </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: <tt>\x</tt> followed by exactly two hexadecimal |
| digits; <tt>\u</tt> followed by exactly four hexadecimal digits; |
| <tt>\U</tt> followed by exactly eight hexadecimal digits, and a |
| plain backslash <tt>\</tt> 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 <tt>\u</tt> and <tt>\U</tt> |
| represent Unicode code points so within them some values are illegal, |
| in particular those above <tt>0x10FFFF</tt> 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 <tt>string</tt>. |
| There are two forms: raw string literals and interpreted string |
| literals. |
| </p> |
| <p> |
| Raw string literals are character sequences between back quotes |
| <tt>``</tt>. 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 <tt>""</tt>. The text between the quotes forms the |
| value of the literal, with backslash escapes interpreted as they |
| are in character literals (except that <tt>\'</tt> is illegal and |
| <tt>\"</tt> is legal). The three-digit octal (<tt>\000</tt>) |
| and two-digit hexadecimal (<tt>\x00</tt>) 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 <tt>\377</tt> and <tt>\xFF</tt> represent |
| a single byte of value <tt>0xFF</tt>=255, while <tt>ÿ</tt>, |
| <tt>\u00FF</tt>, <tt>\U000000FF</tt> and <tt>\xc3\xbf</tt> represent |
| the two bytes <tt>0xc3 0xbf</tt> 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> |
| Adjacent string literals separated only by the empty string, white |
| space, or comments are concatenated into a single string literal. |
| </p> |
| <pre class="grammar"> |
| StringLit = string_lit { string_lit } . |
| </pre> |
| |
| <pre> |
| "Alea iacta est." |
| "Alea " /* The die */ `iacta est` /* is cast */ "." |
| </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>Declarations and scope rules</h2> |
| |
| A declaration ``binds'' an identifier to a language entity (such as |
| a package, constant, type, struct field, variable, parameter, result, |
| function, method) and specifies properties of that entity such as its type. |
| |
| <pre class="grammar"> |
| Declaration = ConstDecl | TypeDecl | VarDecl | FunctionDecl | MethodDecl . |
| </pre> |
| |
| Every identifier in a program must be declared; some identifiers, such as "int" |
| and "true", are predeclared (§Predeclared identifiers). |
| <p> |
| The ``scope'' 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. Go is lexically scoped: An identifier denotes the entity it is |
| bound to only within the scope of the identifier. |
| <p> |
| For instance, for a variable named "x", the scope of identifier "x" is the |
| extent of source text within which "x" denotes that particular variable. |
| It is illegal to declare another identifier "x" within the same scope. |
| <p> |
| The scope of an identifier depends on the entity declared. The scope for |
| an identifier always excludes scopes redeclaring the identifier in nested |
| blocks. An identifier declared in a nested block is said to ``shadow'' the |
| same identifier declared in an outer block. |
| |
| <ol> |
| <li> The scope of predeclared identifiers is the entire source file. |
| |
| <li> The scope of an identifier denoting a type, function or package |
| extends textually from the point of the identifier in the declaration |
| to the end of the innermost surrounding block. |
| |
| <li> The scope of a constant or variable extends textually from |
| after the declaration to the end of the innermost surrounding |
| block. If the variable is declared in the init statement of an |
| if, for, or switch statement, the innermost surrounding block |
| is the block associated with the respective statement. |
| |
| <li> The scope of a parameter or result identifier is the body of the |
| corresponding function. |
| |
| <li> The scope of a field or method identifier is selectors for the |
| corresponding type containing the field or method (§Selectors). |
| |
| <li> The scope of a label is the body of the innermost surrounding |
| function and does not intersect with any non-label scope. Thus, |
| each function has its own private label scope. |
| </ol> |
| |
| <h3>Predeclared identifiers</h3> |
| |
| <p> |
| The following identifiers are predeclared: |
| </p> |
| |
| <p> |
| All basic types: |
| </p> |
| <pre class="grammar"> |
| bool, byte, uint8, uint16, uint32, uint64, int8, int16, int32, int64, |
| float32, float64, string |
| </pre> |
| |
| A set of platform-specific convenience types: |
| |
| <pre class="grammar"> |
| uint, int, float, uintptr |
| </pre> |
| |
| The predeclared constants: |
| |
| <pre class="grammar"> |
| true, false, iota, nil |
| </pre> |
| |
| The predeclared functions (note: this list is likely to change): |
| |
| <pre class="grammar"> |
| cap(), convert(), len(), make(), new(), panic(), panicln(), print(), println(), typeof(), ... |
| </pre> |
| |
| |
| <h3>Exported identifiers</h3> |
| |
| Identifiers that start with a capital_letter (§Identifiers) are ``exported'', |
| thus making the identifiers accessible outside the current package. A file |
| belonging to another package may then import the package (§Packages) and access |
| exported identifiers via qualified identifiers (§Qualified identifiers). |
| <p> |
| All other identifiers are ``internal''; they are only visible in files |
| belonging to the same package which declares them. |
| <p> |
| <font color=red> |
| TODO: This should be made clearer. For instance, function-local identifiers |
| are never exported, but non-global fields/methods may be exported. |
| </font> |
| |
| |
| <h3>Const declarations</h3> |
| |
| A constant declaration binds an identifier to the value of a constant |
| expression (§Constant expressions). |
| |
| <pre class="grammar"> |
| ConstDecl = "const" ( ConstSpec | "(" [ ConstSpecList ] ")" ) . |
| ConstSpecList = ConstSpec { ";" ConstSpec } [ ";" ] . |
| ConstSpec = IdentifierList [ CompleteType ] [ "=" ExpressionList ] . |
| |
| IdentifierList = identifier { "," identifier } . |
| ExpressionList = Expression { "," Expression } . |
| </pre> |
| |
| A constant declaration binds a list of identifiers (the names of the constants) |
| to the values of a list of constant expressions. The number of identifiers must |
| be equal to the number of expressions, with the i'th identifier on the left |
| corresponding to the i'th expression on the right. If CompleteType is omitted, |
| the types of the constants are the types of the corresponding expressions; |
| different expressions may have different types. If CompleteType is present, |
| the type of all constants is the type specified, and the types of all |
| expressions in ExpressionList must be assignment-compatible with the |
| constant type. |
| |
| <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> |
| |
| As a special case, within a parenthesized "const" declaration list the |
| ExpressionList may be omitted from any but the first declaration. Such an empty |
| ExpressionList is equivalent to the textual substitution of the first preceding |
| non-empty ExpressionList in the same "const" declaration list. |
| That is, omitting the list of expressions is equivalent to repeating the |
| previous list. The number of identifiers must be equal to the number of |
| expressions in the previous list. |
| <p> |
| Together with the "iota" constant generator implicit repetition of |
| ExpressionLists permit light-weight declaration of enumerated values (§Iota): |
| |
| <pre> |
| const ( |
| Sunday = iota; |
| Monday; |
| Tuesday; |
| Wednesday; |
| Thursday; |
| Friday; |
| Partyday; |
| numberOfDays; // this constant in not exported |
| ) |
| </pre> |
| |
| The initializing expression for a numeric constant is evaluated |
| using the principles described in the section on numeric literals: |
| constants are mathematical values given a size only upon assignment |
| to a variable. Intermediate values, and the constants themselves, |
| may require precision significantly larger than any concrete type |
| in the language. Thus the following is legal: |
| |
| <pre> |
| const Huge = 1 << 100; |
| const Four int8 = Huge >> 98; |
| </pre> |
| |
| A given numeric constant expression is, however, defined to be |
| either an integer or a floating point value, depending on the syntax |
| of the literals it comprises (123 vs. 1.0e4). This is because the |
| nature of the arithmetic operations depends on the type of the |
| values; for example, 3/2 is an integer division yielding 1, while |
| 3./2. is a floating point division yielding 1.5. Thus |
| |
| <pre> |
| const x = 3./2. + 3/2; |
| </pre> |
| |
| yields a floating point constant of value 2.5 (1.5 + 1); its |
| constituent expressions are evaluated using different rules for |
| division. |
| <p> |
| If the type is missing from a numeric constant declaration, the constant |
| represents a value of abitrary precision, either integer or floating |
| point, determined by the type of the initializing expression. Such |
| a constant may be assigned to any variable that can represent its |
| value accurately, regardless of type. For instance, 3 can be |
| assigned to any integer variable but also to any floating point variable, |
| while 1e12 can be assigned to a "float32", "float64", or even "int64". |
| It is erroneous to assign a value with a non-zero fractional part |
| to an integer, or if the assignment would overflow or underflow. |
| |
| |
| <h3>Iota</h3> |
| |
| Within a constant declaration, the predeclared operand "iota" represents |
| successive elements of an integer sequence. It is reset to 0 whenever the |
| reserved word "const" appears in the source and increments with each |
| semicolon. For instance, "iota" can be used to construct a set of related |
| constants: |
| |
| <pre> |
| const ( // iota is set to 0 |
| enum0 = iota; // sets enum0 to 0, etc. |
| enum1 = iota; |
| enum2 = iota |
| ) |
| |
| 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> |
| |
| Within an ExpressionList, the value of all "iota"'s is the same because "iota" |
| is only incremented at each semicolon: |
| |
| <pre> |
| const ( |
| base0, mask0 int64 = 1 << iota, i << iota - 1; // base0 == 1, mask0 = 0 |
| base1, mask1 int64 = 1 << iota, i << iota - 1; // base1 == 2, mask1 = 1 |
| base2, mask2 int64 = 1 << iota, i << iota - 1; // base2 == 4, mask2 = 3 |
| ) |
| </pre> |
| |
| Since the ExpressionList in constant declarations repeats implicitly |
| if omitted, some of the examples above can be abbreviated: |
| |
| <pre> |
| const ( |
| enum0 = iota; |
| enum1; |
| enum2 |
| ) |
| |
| const ( |
| a = 1 << iota; |
| b; |
| c; |
| ) |
| |
| const ( |
| u = iota * 42; |
| v float; |
| w; |
| ) |
| |
| const ( |
| base0, mask0 int64 = 1 << iota, i << iota - 1; |
| base1, mask1 int64; |
| base2, mask2 int64; |
| ) |
| </pre> |
| |
| |
| <h3>Type declarations</h3> |
| |
| A type declaration specifies a new type and binds an identifier to it. |
| The identifier is called the ``type name''; it denotes the type. |
| |
| <pre class="grammar"> |
| TypeDecl = "type" ( TypeSpec | "(" [ TypeSpecList ] ")" ) . |
| TypeSpecList = TypeSpec { ";" TypeSpec } [ ";" ] . |
| TypeSpec = identifier Type . |
| </pre> |
| |
| A struct or interface type may be forward-declared (§Struct types, |
| §Interface types). A forward-declared type is incomplete (§Types) |
| until it is fully declared. The full declaration must must follow |
| within the same block containing the forward declaration. |
| |
| <pre> |
| type IntArray [16] int |
| |
| type ( |
| Point struct { x, y float }; |
| Polar Point |
| ) |
| |
| type TreeNode struct { |
| left, right *TreeNode; |
| value Point; |
| } |
| |
| type Comparable interface { |
| cmp(Comparable) int |
| } |
| </pre> |
| |
| |
| <h3>Variable declarations</h3> |
| |
| A variable declaration creates a variable, binds an identifier to it and |
| gives it a type. It may optionally give the variable an initial value. |
| The variable type must be a complete type (§Types). |
| In some forms of declaration the type of the initial value defines the type |
| of the variable. |
| |
| <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> |
| |
| If the expression list is present, it must have the same number of elements |
| as there are variables in the variable specification. |
| <p> |
| If the variable type is omitted, an initialization expression (or expression |
| list) must be present, and the variable type is the type of the expression |
| value (in case of a list of variables, the variables assume the types of the |
| corresponding expression values). |
| <p> |
| If the variable type is omitted, and the corresponding initialization expression |
| is a constant expression of abstract int or floating point type, the type |
| of the variable is "int" or "float" respectively: |
| |
| <pre> |
| var i = 0 // i has int type |
| var f = 3.1415 // f has float type |
| </pre> |
| |
| The syntax |
| |
| <pre class="grammar"> |
| SimpleVarDecl = IdentifierList ":=" ExpressionList . |
| </pre> |
| |
| is shorthand for |
| |
| <pre class="grammar"> |
| "var" IdentifierList = ExpressionList . |
| </pre> |
| |
| <pre> |
| i, j := 0, 10; |
| f := func() int { return 7; } |
| ch := new(chan int); |
| </pre> |
| |
| Also, in some contexts such as "if", "for", or "switch" statements, |
| this construct can be used to declare local temporary variables. |
| |
| <hr/> |
| |
| <h2>Types</h2> |
| |
| A type specifies the set of values that variables of that type may assume |
| and the operators that are applicable. |
| <p> |
| A type may be specified by a type name (§Type declarations) or a type literal. |
| A type literal is a syntactic construct that explicitly specifies the |
| composition of a new type in terms of other (already declared) types. |
| |
| <pre class="grammar"> |
| Type = TypeName | TypeLit | "(" Type ")" . |
| TypeName = QualifiedIdent. |
| TypeLit = |
| ArrayType | StructType | PointerType | FunctionType | InterfaceType | |
| SliceType | MapType | ChannelType . |
| </pre> |
| |
| Some types are predeclared and denoted by their type names; these are called |
| ``basic types''. Generally (except for strings) they are not composed of more |
| elementary types; instead they model elementary machine data types. |
| <p> |
| All other types are called ``composite types'; they are composed from other |
| (basic or composite) types and denoted by their type names or by type literals. |
| There are arrays, structs, pointers, functions, interfaces, slices, maps, and |
| channels. |
| <p> |
| At a given point in the source code, a type may be ``complete'' or |
| ''incomplete''. Array and struct types are complete when they are fully declared. |
| All other types are always complete (although their components, such as the base |
| type of a pointer type, may be incomplete). Incomplete types are subject to usage |
| restrictions; for instance the type of a variable must be complete where the |
| variable is declared. |
| |
| <pre class="grammar"> |
| CompleteType = Type . |
| </pre> |
| |
| The ``interface'' of a type is the set of methods bound to it |
| (§Method declarations). The interface of a pointer type is the interface |
| of the pointer base type (§Pointer types). All types have an interface; |
| if they have no methods associated with them, their interface is |
| called the ``empty'' interface. |
| <p> |
| The ``static type'' (or simply ``type'') of a variable is the type defined by |
| the variable's declaration. The ``dynamic type'' of a variable is the actual |
| type of the value stored in a variable at run-time. Except for variables of |
| interface type, the dynamic type of a variable is always its static type. |
| <p> |
| Variables of interface type may hold values with different dynamic types |
| during execution. However, its dynamic type is always compatible with |
| the static type of the interface variable (§Interface types). |
| |
| |
| <h3>Basic types</h3> |
| |
| Go defines a number of basic types, referred to by their predeclared |
| type names. These include traditional arithmetic types, booleans, |
| and strings. |
| |
| |
| <h3>Arithmetic types</h3> |
| |
| The following list enumerates all platform-independent numeric types: |
| |
| <pre class="grammar"> |
| byte same as uint8 (for convenience) |
| |
| 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 |
| </pre> |
| |
| 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. |
| |
| <!-- |
| The representation of signed integers and their exact range is |
| implementation-specific, but the set of all positive values (including zero) |
| of a signed integer type is always a subset of the corresponding unsigned |
| integer type (thus, a positive signed integer can always be converted into |
| its corresponding unsigned type without loss). |
| --> |
| |
| Additionally, Go declares a set of platform-specific numeric types for |
| convenience: |
| |
| <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> |
| |
| For instance, int might have the same size as int32 on a 32-bit |
| architecture, or int64 on a 64-bit architecture. |
| <p> |
| Except for "byte", which is an alias for "uint8", all numeric types |
| are different from each other to avoid portability issues. Conversions |
| are required when different numeric types are mixed in an expression or assignment. |
| For instance, "int32" and "int" are not the same type even though they may have |
| the same size on a particular platform. |
| |
| |
| <h3>Booleans</h3> |
| |
| The type "bool" comprises the truth values true and false, which are |
| available through the two predeclared constants, "true" and "false". |
| |
| |
| <h3>Strings</h3> |
| |
| <p> |
| The "string" type represents the set of string values (strings). |
| Strings behave like arrays of bytes, with the following properties: |
| </p> |
| <ul> |
| <li>They are immutable: after creation, it is not possible to change the |
| contents of a string. |
| <li>No internal pointers: it is illegal to create a pointer to an inner |
| element of a string. |
| <li>They can be indexed: given string "s1", "s1[i]" is a byte value. |
| <li>They can be concatenated: given strings "s1" and "s2", "s1 + s2" is a value |
| combining the elements of "s1" and "s2" in sequence. |
| <li>Known length: the length of a string "s1" can be obtained by calling |
| "len(s1)". The length of a string is the number |
| of bytes within. Unlike in C, there is no terminal NUL byte. |
| <li>Creation 1: a string can be created from an integer value by a conversion; |
| the result is a string containing the UTF-8 encoding of that code point |
| (§Conversions). |
| "string('x')" yields "x"; "string(0x1234)" yields the equivalent of "\u1234" |
| |
| <li>Creation 2: a string can by created from an array of integer values (maybe |
| just array of bytes) by a conversion (§Conversions): |
| <pre> |
| a [3]byte; a[0] = 'a'; a[1] = 'b'; a[2] = 'c'; string(a) == "abc"; |
| </pre> |
| </ul> |
| |
| |
| <h3>Array types</h3> |
| |
| An array is a composite type consisting of a number of elements all of the |
| same type, called the element type. The element type must be a complete type |
| (§Types). The number of elements of an array is called its length; it is never |
| negative. The elements of an array are designated by indices |
| which are integers from 0 through the length - 1. |
| |
| <pre class="grammar"> |
| ArrayType = "[" ArrayLength "]" ElementType . |
| ArrayLength = Expression . |
| ElementType = CompleteType . |
| </pre> |
| |
| The array length and its value are part of the array type. The array length |
| must be a constant expression (§Constant expressions) that evaluates to an |
| integer value >= 0. |
| <p> |
| The number of elements of an array "a" can be discovered using the built-in |
| function |
| |
| <pre> |
| len(a) |
| </pre> |
| |
| The length of arrays is known at compile-time, and the result of a call to |
| "len(a)" is a compile-time constant. |
| |
| <pre> |
| [32]byte |
| [2*N] struct { x, y int32 } |
| [1000]*float64 |
| </pre> |
| |
| Assignment compatibility: Arrays can be assigned to variables of equal type |
| and 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. |
| |
| |
| <h3>Struct types</h3> |
| |
| A struct is a composite type consisting of a fixed number of elements, |
| called fields, with possibly different types. A struct type declares |
| an identifier and type for each field. Within a struct type no field |
| identifier may be declared twice and all field types must be complete |
| types (§Types). |
| |
| <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> |
| |
| A struct may contain ``anonymous fields'', which are declared with a type |
| but no explicit field identifier. An anonymous field type must be specified as |
| a type name "T", or as a pointer to a type name ``*T'', and T itself may not be |
| a pointer or interface type. The unqualified type name acts as the field identifier. |
| |
| <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 the unqualified type name T3 |
| *P.T4; // the field name is the unqualified type name T4 |
| x, y int; |
| } |
| </pre> |
| |
| 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: |
| |
| <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> |
| |
| Fields and methods (§Method declarations) of an anonymous field become directly |
| accessible as fields and methods of the struct without the need to provide the |
| type name of the respective anonymous field (§Selectors). |
| <p> |
| A field declaration may be followed by an optional string literal tag which |
| becomes an ``attribute'' for all the identifiers in the corresponding |
| field declaration. The tags are available via the reflection library but |
| are ignored otherwise. A tag may contain arbitrary application-specific |
| information. |
| |
| <pre> |
| // A struct corresponding to the EventIdMessage protocol buffer. |
| // The tag strings contain the protocol buffer field tags. |
| struct { |
| time_usec uint64 "1"; |
| server_ip uint32 "2"; |
| process_id uint32 "3"; |
| } |
| </pre> |
| |
| Forward declaration: |
| A struct type consisting of only the reserved word "struct" may be used in |
| a type declaration; it declares an incomplete struct type (§Type declarations). |
| This allows the construction of mutually recursive types such as: |
| |
| <pre> |
| type S2 struct // forward declaration of S2 |
| type S1 struct { s2 *S2 } |
| type S2 struct { s1 *S1 } |
| </pre> |
| |
| Assignment compatibility: Structs are assignment compatible to variables of |
| equal type only. |
| |
| |
| <h3>Pointer types</h3> |
| |
| A pointer type denotes the set of all pointers to variables of a given |
| type, called the ``base type'' of the pointer, and the value "nil". |
| |
| <pre class="grammar"> |
| PointerType = "*" BaseType . |
| BaseType = Type . |
| </pre> |
| |
| <pre> |
| *int |
| map[string] chan |
| </pre> |
| |
| The pointer base type may be denoted by an identifier referring to an |
| incomplete type (§Types), possibly declared via a forward declaration. |
| This allows the construction of recursive and mutually recursive types |
| such as: |
| |
| <pre> |
| type S struct { s *S } |
| |
| type S2 struct // forward declaration of S2 |
| type S1 struct { s2 *S2 } |
| type S2 struct { s1 *S1 } |
| </pre> |
| |
| Assignment compatibility: A pointer is assignment compatible to a variable |
| of pointer type, only if both types are equal. |
| <p> |
| Comparisons: A variable of pointer type can be compared against "nil" with the |
| operators "==" and "!=" (§Comparison operators). The variable is |
| "nil" only if "nil" is assigned explicitly to the variable (§Assignments), or |
| if the variable has not been modified since creation (§Program initialization |
| and execution). |
| <p> |
| Two variables of equal pointer type can be tested for equality with the |
| operators "==" and "!=" (§Comparison operators). The pointers are equal |
| if they point to the same location. |
| |
| Pointer arithmetic of any kind is not permitted. |
| |
| |
| <h3>Function types</h3> |
| |
| A function type denotes the set of all functions with the same parameter |
| and result types, and the value "nil". |
| |
| <pre class="grammar"> |
| FunctionType = "func" Signature . |
| Signature = "(" [ ParameterList ] ")" [ Result ] . |
| ParameterList = ParameterDecl { "," ParameterDecl } . |
| ParameterDecl = [ IdentifierList ] ( Type | "..." ) . |
| Result = Type | "(" ParameterList ")" . |
| </pre> |
| |
| In ParameterList, the parameter names (IdentifierList) either must all be |
| present, or all be absent. If the parameters are named, each name stands |
| for one parameter of the specified type. If the parameters are unnamed, each |
| type stands for one parameter of that type. |
| <p> |
| For the last incoming parameter only, instead of a parameter type one |
| may write "...". The ellipsis indicates that the last parameter stands |
| for an arbitrary number of additional arguments of any type (including |
| no additional arguments). If the parameters are named, the identifier |
| list immediately preceding "..." must contain only one identifier (the |
| name of the last parameter). |
| |
| <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) |
| </pre> |
| |
| If the result type of a function is itself a function type, the result type |
| must be parenthesized to resolve a parsing ambiguity: |
| |
| <pre> |
| func (n int) (func (p* T)) |
| </pre> |
| |
| Assignment compatibility: A function can be assigned to a function |
| variable only if both function types are equal. |
| <p> |
| Comparisons: A variable of function type can be compared against "nil" with the |
| operators "==" and "!=" (§Comparison operators). The variable is |
| "nil" only if "nil" is assigned explicitly to the variable (§Assignments), or |
| if the variable has not been modified since creation (§Program initialization |
| and execution). |
| <p> |
| Two variables of equal function type can be tested for equality with the |
| operators "==" and "!=" (§Comparison operators). The variables are equal |
| if they refer to the same function. |
| |
| |
| <h3>Interface types</h3> |
| |
| Type interfaces may be specified explicitly by interface types. |
| An interface type denotes the set of all types that implement at least |
| the set of methods specified by the interface type, and the value "nil". |
| |
| <pre class="grammar"> |
| InterfaceType = "interface" [ "{" [ MethodSpecList ] "}" ] . |
| MethodSpecList = MethodSpec { ";" MethodSpec } [ ";" ] . |
| MethodSpec = IdentifierList Signature | TypeName . |
| </pre> |
| |
| <pre> |
| // An interface specifying a basic File type. |
| interface { |
| Read, Write (b Buffer) bool; |
| Close (); |
| } |
| </pre> |
| |
| Any type (including interface types) whose interface has, possibly as a |
| subset, the complete set of methods of an interface I is said to implement |
| interface I. For instance, if two types S1 and S2 have the methods |
| |
| <pre> |
| func (p T) Read(b Buffer) bool { return ... } |
| func (p T) Write(b Buffer) bool { return ... } |
| func (p T) Close() { ... } |
| </pre> |
| |
| (where T stands for either S1 or S2) then the File interface is |
| implemented by both S1 and S2, regardless of what other methods |
| S1 and S2 may have or share. |
| |
| All types implement the empty interface: |
| |
| <pre> |
| interface {} |
| </pre> |
| |
| In general, a type implements an arbitrary number of interfaces. |
| For instance, consider the interface |
| |
| <pre> |
| type Lock interface { |
| Lock, Unlock (); |
| } |
| </pre> |
| |
| If S1 and S2 also implement |
| |
| <pre> |
| func (p T) Lock() { ... } |
| func (p T) Unlock() { ... } |
| </pre> |
| |
| they implement the Lock interface as well as the File interface. |
| <p> |
| An interface may contain a type name T in place of a method specification. |
| T must denote another, complete (and not forward-declared) interface type. |
| Using this notation is equivalent to enumerating the methods of T explicitly |
| in the interface containing T. |
| |
| <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> |
| |
| Forward declaration: |
| A interface type consisting of only the reserved word "interface" may be used in |
| a type declaration; it declares an incomplete interface type (§Type declarations). |
| This allows the construction of mutually recursive types such as: |
| |
| <pre> |
| type T2 interface |
| type T1 interface { |
| foo(T2) int; |
| } |
| type T2 interface { |
| bar(T1) int; |
| } |
| </pre> |
| |
| Assignment compatibility: A value can be assigned to an interface variable |
| if the static type of the value implements the interface or if the value is "nil". |
| <p> |
| Comparisons: A variable of interface type can be compared against "nil" with the |
| operators "==" and "!=" (§Comparison operators). The variable is |
| "nil" only if "nil" is assigned explicitly to the variable (§Assignments), or |
| if the variable has not been modified since creation (§Program initialization |
| and execution). |
| <p> |
| Two variables of interface type can be tested for equality with the |
| operators "==" and "!=" (§Comparison operators) if both variables have the |
| same static type. They are equal if both their dynamic types and values are |
| equal. If the dynamic types are equal but the values do not support comparison, |
| a run-time error occurs. |
| |
| |
| <h3>Slice types</h3> |
| |
| A slice type denotes the set of all slices (segments) of arrays |
| (§Array types) of a given element type, and the value "nil". |
| The number of elements of a slice is called its length; it is never negative. |
| The elements of a slice are designated by indices which are |
| integers from 0 through the length - 1. |
| |
| <pre class="grammar"> |
| SliceType = "[" "]" ElementType . |
| </pre> |
| |
| Syntactically and semantically, arrays and slices look and behave very |
| similarly, but with one important difference: A slice is a descriptor |
| of an array segment; in particular, different variables of a slice type may |
| refer to different (and possibly overlapping) segments of the same underlying |
| array. Thus, with respect to the underlying array, slices behave like |
| references. In contrast, two different variables of array type always |
| denote two different arrays. |
| <p> |
| For slices, the actual array underlying the slice may extend past the current |
| slice length; the maximum length a slice may assume is called its capacity. |
| The capacity of any slice "a" can be discovered using the built-in function |
| |
| <pre> |
| cap(a) |
| </pre> |
| |
| and the following relationship between "len()" and "cap()" holds: |
| |
| <pre> |
| 0 <= len(a) <= cap(a) |
| </pre> |
| |
| The value of an uninitialized slice is "nil", and its length and capacity |
| are 0. A new, initialized slice value for a given element type T is |
| made using the built-in function "make", which takes a slice type |
| and parameters specifying the length and optionally the capacity: |
| |
| <pre> |
| make([]T, length) |
| make([]T, length, capacity) |
| </pre> |
| |
| The "make()" call allocates a new underlying array to which the returned |
| slice value refers. More precisely, calling "make" |
| |
| <pre> |
| make([]T, length, capacity) |
| </pre> |
| |
| is effectively the same as allocating an array and slicing it |
| |
| <pre> |
| new([capacity]T)[0 : length] |
| </pre> |
| |
| Assignment compatibility: Slices are assignment compatible to variables |
| of the same type. |
| <p> |
| Indexing: Given a (pointer to) a slice variable "a", a slice element is |
| specified with an index operation: |
| |
| <pre> |
| a[i] |
| </pre> |
| |
| This denotes the slice element at index "i". "i" must be within bounds, |
| that is "0 <= i < len(a)". |
| <p> |
| Slicing: Given a a slice variable "a", a sub-slice is created with a slice |
| operation: |
| |
| <pre> |
| a[i : j] |
| </pre> |
| |
| This creates the sub-slice consisting of the elements "a[i]" through "a[j - 1]" |
| (that is, excluding "a[j]"). The values "i" and "j" must satisfy the condition |
| "0 <= i <= j <= cap(a)". The length of the new slice is "j - i". The capacity of |
| the slice is "cap(a) - i"; thus if "i" is 0, the slice capacity does not change |
| as a result of a slice operation. The type of a sub-slice is the same as the |
| type of the slice. Unlike the capacity, the length of a sub-slice may be larger |
| than the length of the original slice. |
| <p> |
| Comparisons: A variable of slice type can be compared against "nil" with the |
| operators "==" and "!=" (§Comparison operators). The variable is |
| "nil" only if "nil" is assigned explicitly to the variable (§Assignments), or |
| if the variable has not been modified since creation (§Program initialization |
| and execution). |
| |
| |
| <h3>Map types</h3> |
| |
| A map is a composite type consisting of a variable number of entries |
| called (key, value) pairs. For a given map, the keys and values must |
| each be of a specific complete type (§Types) called the key and value type, |
| respectively. The number of entries in a map is called its length; it is never |
| negative. |
| |
| <pre class="grammar"> |
| MapType = "map" "[" KeyType "]" ValueType . |
| KeyType = CompleteType . |
| ValueType = CompleteType . |
| </pre> |
| |
| The comparison operators "==" and "!=" (§Comparison operators) must be defined |
| for operands of the key type; thus the key type must be a basic, pointer, |
| interface, or channel type. If the key type is an interface type, |
| the dynamic key types must support these comparison operators. In this case, |
| inserting a map value with a key that does not support testing for equality |
| is a run-time error. |
| <p> |
| Upon creation, a map is empty and values may be added and removed |
| during execution. |
| |
| <pre> |
| map [string] int |
| map [*T] struct { x, y float } |
| map [string] interface {} |
| </pre> |
| |
| The length of a map "m" can be discovered using the built-in function |
| |
| <pre> |
| len(m) |
| </pre> |
| |
| The value of an uninitialized map is "nil". A new, empty map value for given |
| map type M is made using the built-in function "make" which takes the map type |
| and an optional capacity as arguments: |
| |
| <pre> |
| my_map := make(M, 100); |
| </pre> |
| |
| The map capacity is an allocation hint for more efficient incremental growth |
| of the map. |
| <p> |
| Assignment compatibility: A map type is assignment compatible to a variable of |
| map type only if both types are equal. |
| <p> |
| Comparisons: A variable of map type can be compared against "nil" with the |
| operators "==" and "!=" (§Comparison operators). The variable is |
| "nil" only if "nil" is assigned explicitly to the variable (§Assignments), or |
| if the variable has not been modified since creation (§Program initialization |
| and execution). |
| |
| |
| <h3>Channel types</h3> |
| |
| A channel provides a mechanism for two concurrently executing functions |
| to synchronize execution and exchange values of a specified type. This |
| type must be a complete type (§Types). <font color=red>(TODO could it be incomplete?)</font> |
| |
| <pre class="grammar"> |
| ChannelType = Channel | SendChannel | RecvChannel . |
| Channel = "chan" ValueType . |
| SendChannel = "chan" "<-" ValueType . |
| RecvChannel = "<-" "chan" ValueType . |
| </pre> |
| |
| Upon creation, a channel can be used both to send and to receive. |
| By conversion or assignment, a channel may be constrained only to send or |
| to receive. This constraint is called a channel's ``direction''; either |
| bi-directional (unconstrained), send, or receive. |
| |
| <pre> |
| chan T // can send and receive values of type T |
| chan <- float // can only be used to send floats |
| <-chan int // can only receive ints |
| </pre> |
| |
| The value of an uninitialized channel is "nil". A new, initialized channel |
| value for a given element type T is made using the built-in function "make", |
| which takes the channel type and an optional capacity as arguments: |
| |
| <pre> |
| my_chan = make(chan int, 100); |
| </pre> |
| |
| The capacity sets the size of the buffer in the communication 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, |
| the communication succeeds only when both a sender and receiver are ready. |
| <p> |
| Assignment compatibility: A value of type channel can be assigned to a variable |
| of type channel only if a) both types are equal (§Type equality), or b) both |
| have equal channel value types and the value is a bidirectional channel. |
| <p> |
| Comparisons: A variable of channel type can be compared against "nil" with the |
| operators "==" and "!=" (§Comparison operators). The variable is |
| "nil" only if "nil" is assigned explicitly to the variable (§Assignments), or |
| if the variable has not been modified since creation (§Program initialization |
| and execution). |
| <p> |
| Two variables of channel type can be tested for equality with the |
| operators "==" and "!=" (§Comparison operators) if both variables have |
| the same ValueType. They are equal if both values were created by the same |
| "make" call (§Making slices, maps, and channels). |
| |
| |
| <h3>Type equality</h3> |
| |
| <p> |
| Types may be ``different'', ``structurally equal'', or ``identical''. |
| Go is a type-safe language; generally different types cannot be mixed |
| in binary operations, and values cannot be assigned to variables of different |
| types. However, values may be assigned to variables of structurally |
| equal types. Finally, type guards succeed only if the dynamic type |
| is identical to or implements the type tested against (§Type guards). |
| <p> |
| Structural type equality (equality for short) is defined by these rules: |
| <p> |
| Two type names denote equal types if the types in the corresponding declarations |
| are equal. Two type literals specify equal types if they have the same |
| literal structure and corresponding components have equal types. Loosely |
| speaking, two types are equal if their values have the same layout in memory. |
| More precisely: |
| </p> |
| <ul> |
| <li>Two array types are equal if they have equal element types and if they |
| have the same array length. |
| |
| <li>Two struct types are equal if they have the same number of fields in the |
| same order, corresponding fields either have both the same name or |
| are both anonymous, and corresponding field types are identical. |
| |
| <li>Two pointer types are equal if they have equal base types. |
| |
| <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 |
| equal (a "..." parameter is equal to another "..." parameter). |
| Note that parameter and result names do not have to match. |
| |
| <li>Two slice types are equal if they have equal element types. |
| |
| <li>Two channel types are equal if they have equal value types and |
| the same direction. |
| |
| <li>Two map types are equal if they have equal key and value types. |
| |
| <li>Two interface types are equal if they have the same set of methods |
| with the same names and equal function types. Note that the order |
| of the methods in the respective type declarations is irrelevant. |
| </ul> |
| |
| <p> |
| Type identity is defined by these rules: |
| </p> |
| <p> |
| Two type names denote identical types if they originate in the same |
| type declaration. Two type literals specify identical types if they have the |
| same literal structure and corresponding components have identical types. |
| More precisely: |
| </p> |
| <ul> |
| <li>Two array types are identical if they have identical element types and if |
| they have the same array length. |
| |
| <li>Two struct types are identical if they have the same number of fields in |
| the same order, corresponding fields either have both the same name or |
| are both anonymous, and corresponding field types are identical. |
| |
| <li>Two pointer types are identical if they have identical base types. |
| |
| <li>Two function types are identical if they have the same number of |
| parameters and result values both with the same (or absent) names, and |
| if corresponding parameter and result types are identical (a "..." |
| parameter is identical to another "..." parameter with the same name). |
| |
| <li>Two slice types are identical if they have identical element types. |
| |
| <li>Two channel types are identical if they have identical value types and |
| the same direction. |
| |
| <li>Two map types are identical if they have identical key and value types. |
| |
| <li>Two interface types are identical if they have the same set of methods |
| with the same names and identical function types. Note that the order |
| of the methods in the respective type declarations is irrelevant. |
| </ul> |
| |
| Note that the type denoted by a type name is identical only to the type literal |
| in the type name's declaration. |
| <p> |
| Finally, two types are different if they are not structurally equal. |
| (By definition, they cannot be identical, either). |
| |
| For instance, given the declarations |
| |
| <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> |
| |
| these are some types that are equal |
| |
| <pre> |
| T0 and T0 |
| T0 and []string |
| T2 and T3 |
| T4 and T5 |
| T3 and struct { a int; int } |
| </pre> |
| |
| and these are some types that are identical |
| |
| <pre> |
| T0 and T0 |
| []int and []int |
| struct { a, b *T5 } and struct { a, b *T5 } |
| </pre> |
| |
| As an example, "T0" and "T1" are equal but not identical because they have |
| different declarations. |
| |
| <hr/> |
| |
| <h2>Expressions</h2> |
| |
| An expression specifies the computation of a value via the application of |
| operators and function invocations on operands. An expression has a value and |
| a type. |
| <p> |
| The type of a constant expression may be an ideal number. The type of such expressions |
| is implicitly converted into the 'expected numeric type' required for the expression. |
| The conversion is legal if the (ideal) expression value is a member of the |
| set represented by the expected numeric type. In all other cases, and specifically |
| if the expected type is not a numeric type, the expression is erroneous. |
| <p> |
| For instance, if the expected numeric type is a uint32, any ideal number |
| which fits into a uint32 without loss of precision can be legally converted. |
| Thus, the values 991, 42.0, and 1e9 are ok, but -1, 3.14, or 1e100 are not. |
| |
| <!-- |
| TODO(gri) This may be overly constraining. What about "len(a) + c" where |
| c is an ideal number? Is len(a) of type int, or of an ideal number? Probably |
| should be ideal number, because for arrays, it is a constant. |
| --> |
| |
| |
| <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> |
| |
| An operand is called ``constant'' if it is a literal of a basic type |
| (including the predeclared constants "true" and "false", and the values |
| denoted by "iota"), the predeclared constant "nil", or a parenthesized |
| constant expression (§Constant expressions). Constants have values that |
| are known at compile-time. |
| |
| |
| <h3>Qualified identifiers</h3> |
| |
| A qualified identifier is an identifier qualified by a package name. |
| <p> |
| <font color=red> |
| TODO(gri) expand this section. |
| </font> |
| |
| <pre class="grammar"> |
| QualifiedIdent = { PackageName "." } identifier . |
| PackageName = identifier . |
| </pre> |
| |
| |
| <h3>Composite literals</h3> |
| |
| Literals for composite data structures consist of the type of the value |
| followed by a braced expression list for array, slice, and structure literals, |
| or a list of expression pairs for map literals. |
| |
| <pre class="grammar"> |
| CompositeLit = LiteralType "(" [ ( ExpressionList | ExprPairList ) [ "," ] ] ")" . |
| LiteralType = Type | "[" "..." "]" ElementType . |
| ExprPairList = ExprPair { "," ExprPair } . |
| ExprPair = Expression ":" Expression . |
| </pre> |
| |
| The LiteralType must be an struct, array, slice, or map type. |
| The types of the expressions must match the respective field, element, and |
| key types of the LiteralType; there is no automatic type conversion. |
| Composite literals are values of the type specified by LiteralType; that is |
| a new value is created every time the literal is evaluated. To get |
| a pointer to the literal, the address operator "&" must be used. |
| <p> |
| Given |
| |
| <pre> |
| type Rat struct { num, den int } |
| type Num struct { r Rat; f float; s string } |
| </pre> |
| |
| one can write |
| |
| <pre> |
| pi := Num(Rat(22, 7), 3.14159, "pi"); |
| </pre> |
| |
| 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 appropriate zero value for the array element type. |
| It is an error to provide more elements than specified in LiteralType. The |
| notation "..." may be used in place of the length expression to denote a |
| length equal to the number of elements in the literal. |
| |
| <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> |
| |
| A slice literal is a slice describing the entire underlying array literal. |
| Thus, the length and capacity of a slice literal is the number of elements |
| provided in the literal. A slice literal of the form |
| |
| <pre> |
| []T(x1, x2, ... xn) |
| </pre> |
| |
| is essentially a shortcut for a slice operation applied to an array literal: |
| |
| <pre> |
| [n]T(x1, x2, ... xn)[0 : n] |
| </pre> |
| |
| Map literals are similar except the elements of the expression list are |
| key-value pairs separated by a colon: |
| |
| <pre> |
| m := map[string]int("good": 0, "bad": 1, "indifferent": 7); |
| </pre> |
| |
| <font color=red> |
| TODO: Consider adding helper syntax for nested composites |
| (avoids repeating types but complicates the spec needlessly.) |
| </font> |
| |
| |
| <h3>Function literals</h3> |
| |
| A function literal represents an anonymous function. It consists of a |
| specification of the function type and the function body. The parameter |
| and result types of the function type must all be complete types (§Types). |
| |
| <pre class="grammar"> |
| FunctionLit = "func" Signature Block . |
| Block = "{" [ StatementList ] "}" . |
| </pre> |
| |
| The type of a function literal is the function type specified. |
| |
| <pre> |
| func (a, b int, z float) bool { return a*b < int(z); } |
| </pre> |
| |
| A function literal can be assigned to a variable of the |
| corresponding function type, or invoked directly. |
| |
| <pre> |
| f := func(x, y int) int { return x + y; } |
| func(ch chan int) { ch <- ACK; } (reply_chan) |
| </pre> |
| |
| Function literals are "closures": 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 in any way. |
| |
| |
| <h3>Primary expressions</h3> |
| |
| <pre class="grammar"> |
| PrimaryExpr = |
| Operand | |
| PrimaryExpr Selector | |
| PrimaryExpr Index | |
| PrimaryExpr Slice | |
| PrimaryExpr TypeGuard | |
| PrimaryExpr Call . |
| |
| Selector = "." identifier . |
| Index = "[" Expression "]" . |
| Slice = "[" Expression ":" Expression "]" . |
| TypeGuard = "." "(" 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> |
| |
| A primary expression of the form |
| |
| <pre> |
| x.f |
| </pre> |
| |
| denotes the field or method f of the value denoted by x (or of *x if |
| x is of pointer type). The identifier f is called the (field or method) |
| ``selector''. |
| <p> |
| A selector f may denote a field f declared in a type T, or it may refer |
| to a field f declared in a nested anonymous field of T. Analogously, |
| f may denote a method f of T, or it may refer to a method f of the type |
| of a nested anonymous field of T. The number of anonymous fields traversed |
| to get to the field or method is called its ``depth'' in T. |
| <p> |
| More precisely, the depth of a field or method f declared in T is zero. |
| The depth of a field or method f declared anywhere inside |
| an anonymous field A declared in T is the depth of f in A plus one. |
| <p> |
| The following rules apply to selectors: |
| <p> |
| 1) For a value x of type T or *T where T is not an interface type, |
| x.f denotes the field or method at the shallowest depth in T where there |
| is such an f. The type of x.f is the type of the field or method f. |
| If there is not exactly one f with shallowest depth, the selector |
| expression is illegal. |
| <p> |
| 2) For a variable x of type I or *I where I is an interface type, |
| x.f denotes the actual method with name f of the value assigned |
| to x if there is such a method. The type of x.f is the type |
| of the method f. If no value or nil was assigned to x, x.f is illegal. |
| <p> |
| 3) In all other cases, x.f is illegal. |
| <p> |
| Thus, selectors automatically dereference pointers as necessary. For instance, |
| for an x of type *T where T declares an f, x.f is a shortcut for (*x).f. |
| Furthermore, for an x of type T containing an anonymous field A declared as *A |
| inside T, and where A contains a field f, x.f is a shortcut for (*x.A).f |
| (assuming that the selector is legal in the first place). |
| <p> |
| The following examples illustrate selector use in more detail. Given the |
| declarations: |
| |
| <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> |
| |
| one can write: |
| |
| <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> |
| |
| A primary expression of the form |
| |
| <pre> |
| a[x] |
| </pre> |
| |
| <p> |
| denotes the array or map element x. The value x is called the |
| ``array index'' or ``map key'', respectively. The following |
| rules apply: |
| </p> |
| <p> |
| For a of type A or *A where A is an array type (§Array types): |
| </p> |
| <ul> |
| <li>x must be an integer value and 0 <= x < len(a) |
| <li>a[x] is the array element at index x and the type of a[x] |
| is the element type of A |
| </ul> |
| <p> |
| For a of type *M, where M is a map type (§Map types): |
| </p> |
| <ul> |
| <li>x must be of the same type as the key type of M |
| and the map must contain an entry with key x |
| <li>a[x] is the map value with key x and the type of a[x] |
| is the value type of M |
| </ul> |
| |
| Otherwise a[x] is illegal. |
| <p> |
| <font color=red> |
| TODO: Need to expand map rules for assignments of the form v, ok = m[k]. |
| </font> |
| |
| |
| <h3>Slices</h3> |
| |
| Strings, arrays, and slices can be ``sliced'' 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 "a" |
| |
| <pre> |
| a := [4]int(1, 2, 3, 4); |
| s := a[1:3]; |
| </pre> |
| |
| the slice "s" has type "[]int", length 2, and elements |
| |
| <pre> |
| s[0] == 2 |
| s[1] == 3 |
| </pre> |
| |
| The index values in the slice must be in bounds for the original |
| array (or string) and the slice length must be non-negative. |
| <p> |
| If the sliced operand is a string, the result of the slice operation is another |
| string (§String types). If the sliced operand is an array or slice, the result |
| of the slice operation is a slice (§Slice types). |
| |
| |
| <h3>Type guards</h3> |
| |
| For an expression "x" and a type "T", the primary expression |
| |
| <pre> |
| x.(T) |
| </pre> |
| |
| asserts that the value stored in "x" is an element of type "T" (§Types). |
| The notation ".(T)" is called a ``type guard'', and "x.(T)" is called |
| a ``guarded expression''. The type of "x" must be an interface type. |
| <p> |
| More precisely, if "T" is not an interface type, the expression asserts |
| that the dynamic type of "x" is identical to the type "T" (§Types). |
| If "T" is an interface type, the expression asserts that the dynamic type |
| of T implements the interface "T" (§Interface types). Because it can be |
| verified statically, a type guard in which the static type of "x" implements |
| the interface "T" is illegal. The type guard is said to succeed if the |
| assertion holds. |
| <p> |
| If the type guard succeeds, the value of the guarded expression is the value |
| stored in "x" and its type is "T". If the type guard fails, a run-time |
| exception occurs. In other words, even though the dynamic type of "x" |
| is only known at run-time, the type of the guarded expression "x.(T)" is |
| known to be "T" in a correct program. |
| <p> |
| As a special form, if a guarded expression is used in an assignment |
| |
| <pre> |
| v, ok = x.(T) |
| v, ok := x.(T) |
| </pre> |
| |
| the result of the guarded expression is a pair of values with types "(T, bool)". |
| If the type guard succeeds, the expression returns the pair "(x.(T), true)"; |
| that is, the value stored in "x" (of type "T") is assigned to "v", and "ok" |
| is set to true. If the type guard fails, the value in "v" is set to the initial |
| value for the type of "v" (§Program initialization and execution), and "ok" is |
| set to false. No run-time exception occurs in this case. |
| <p> |
| <font color=red> |
| TODO add examples |
| </font> |
| |
| |
| <h3>Calls</h3> |
| |
| <font color=red> |
| TODO: This needs to be expanded and cleaned up. |
| </font> |
| |
| Given a function or a function variable p, one writes |
| |
| <pre> |
| p() |
| </pre> |
| |
| to call the function. |
| <p> |
| A method is called using the notation |
| |
| <pre> |
| receiver.method() |
| </pre> |
| |
| where receiver is a value of the receiver type of the method. |
| <p> |
| For instance, given a *Point variable pt, one may call |
| |
| <pre> |
| pt.Scale(3.5) |
| </pre> |
| |
| The type of a method is the type of a function with the receiver as first |
| argument. For instance, the method "Scale" has type |
| |
| <pre> |
| (p *Point, factor float) |
| </pre> |
| |
| However, a function declared this way is not a method. |
| <p> |
| There is no distinct method type and there are no method literals. |
| |
| |
| <h3>Parameter passing</h3> |
| |
| <font color=red> |
| TODO expand this section (right now only "..." parameters are covered). |
| </font> |
| |
| Inside a function, the type of the "..." parameter is the empty interface |
| "interface {}". The dynamic type of the parameter - that is, the type of |
| the value stored in the parameter - is of the form (in pseudo- |
| notation) |
| |
| <pre> |
| *struct { |
| arg(0) typeof(arg(0)); |
| arg(1) typeof(arg(1)); |
| arg(2) typeof(arg(2)); |
| ... |
| arg(n-1) typeof(arg(n-1)); |
| } |
| </pre> |
| |
| where the "arg(i)"'s correspond to the actual arguments passed in place |
| of the "..." parameter (the parameter and type names are for illustration |
| only). Reflection code may be used to access the struct value and its fields. |
| Thus, arguments provided in place of a "..." parameter are wrapped into |
| a corresponding struct, and a pointer to the struct is passed to the |
| function instead of the actual arguments. |
| |
| For instance, consider the function |
| |
| <pre> |
| func f(x int, s string, f_extra ...) |
| </pre> |
| |
| and the call |
| |
| <pre> |
| f(42, "foo", 3.14, true, []int(1, 2, 3)) |
| </pre> |
| |
| Upon invocation, the parameters "3.14", "true", and "[]int(1, 2, 3)" |
| are wrapped into a struct and the pointer to the struct is passed to f. |
| In f the type of parameter "f_extra" is "interface{}". |
| The dynamic type of "f_extra" is the type of the value assigned |
| to it upon invocation (the field names "arg0", "arg1", "arg2" are made |
| up for illustration only, they are not accessible via reflection): |
| |
| <pre> |
| *struct { |
| arg0 float; |
| arg1 bool; |
| arg2 []int; |
| } |
| </pre> |
| |
| The values of the fields "arg0", "arg1", and "arg2" are "3.14", "true", |
| and "[]int(1, 2, 3)". |
| <p> |
| As a special case, if a function passes a "..." parameter as the argument |
| for a "..." parameter of a function, the parameter is not wrapped again into |
| a struct. Instead it is passed along unchanged. For instance, the function |
| f may call a function g with declaration |
| |
| <pre> |
| func g(x int, g_extra ...) |
| </pre> |
| |
| as |
| |
| <pre> |
| g(x, f_extra); |
| </pre> |
| |
| Inside g, the value stored in g_extra is the same as the value stored |
| in f_extra. |
| |
| |
| <h3>Operators</h3> |
| |
| Operators combine operands into expressions. |
| |
| <pre class="grammar"> |
| Expression = UnaryExpr | Expression binaryOp 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>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 (§Expression). |
| |
| <li>If both operands are ideal numbers, the conversion is to ideal floats |
| if one of the operands is an ideal float (relevant for "/" and "%"). |
| |
| <li>The right operand in a shift operation must be always be an unsigned int |
| (or an ideal number that can be safely converted into an unsigned int) |
| (§Arithmetic operators). |
| |
| <li>When comparing two operands of channel type, the channel value types |
| must be equal but the channel direction is ignored. |
| </ul> |
| |
| Unary operators have the highest precedence. They are evaluated from |
| right to left. Note that "++" and "--" are outside the unary operator |
| hierarchy (they are statements) and they apply to the operand on the left. |
| Specifically, "*p++" means "(*p)++" in Go (as opposed to "*(p++)" in C). |
| <p> |
| There are six precedence levels for binary operators: |
| multiplication operators bind strongest, followed by addition |
| operators, comparison operators, communication operators, |
| "&&" (logical and), and finally "||" (logical or) with the |
| lowest precedence: |
| |
| <pre class="grammar"> |
| Precedence Operator |
| 6 * / % << >> & |
| 5 + - | ^ |
| 4 == != < <= > >= |
| 3 <- |
| 2 && |
| 1 || |
| </pre> |
| |
| Binary operators of the same precedence associate from left to right. |
| For instance, "x / y / z" stands for "(x / y) / z". |
| <p> |
| Examples |
| |
| <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 ("+", "-", |
| "*", "/") apply to both integer and floating point types, while "+" also applies |
| to strings and arrays; all other arithmetic operators apply to integer types only. |
| |
| <pre class="grammar"> |
| + sum integers, floats, strings, arrays |
| - difference integers, floats |
| * product integers, floats |
| / quotient integers, floats |
| % remainder integers |
| |
| & bitwise and integers |
| | bitwise or integers |
| ^ bitwise xor integers |
| |
| << left shift integer << unsigned integer |
| >> right shift integer >> unsigned integer |
| </pre> |
| |
| Strings can be concatenated using the "+" operator (or the "+=" assignment): |
| |
| <pre> |
| s := "hi" + string(c) |
| </pre> |
| |
| String addition creates a new string by copying the elements. |
| <p> |
| For integer values, "/" and "%" satisfy the following relationship: |
| |
| <pre> |
| (a / b) * b + a % b == a |
| </pre> |
| |
| and |
| |
| <pre> |
| (a / b) is "truncated towards zero". |
| </pre> |
| |
| Examples: |
| |
| <pre> |
| x y x / y x % y |
| 5 3 1 2 |
| -5 3 -1 -2 |
| 5 -3 -1 2 |
| -5 -3 1 -2 |
| </pre> |
| |
| Note that 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: |
| |
| <pre> |
| x x / 4 x % 4 x >> 2 x & 3 |
| 11 2 3 2 3 |
| -11 -2 -3 -3 1 |
| </pre> |
| |
| 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. It is |
| as if the left operand is shifted "n" times by 1 for a shift count of "n". |
| Specifically, "x << 1" is the same as "x*2"; and "x >> 1" is the same as |
| "x/2 truncated towards negative infinity". |
| |
| For integer operands, the unary operators "+", "-", and "^" are defined as |
| follows: |
| |
| <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> |
| |
| |
| <h3>Integer overflow</h3> |
| |
| For unsigned integer values, the operations "+", "-", "*", and "<<" are |
| computed modulo 2^n, where n is the bit width of the unsigned integer type |
| (§Arithmetic types). Loosely speaking, these unsigned integer operations |
| discard high bits upon overflow, and programs may rely on ``wrap around''. |
| <p> |
| For signed integers, the operations "+", "-", "*", and "<<" 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. As a consequence, a |
| compiler may not optimize code under the assumption that overflow does |
| not occur. For instance, it may not assume that "x < x + 1" is always true. |
| |
| |
| <h3>Comparison operators</h3> |
| |
| Comparison operators yield a boolean result. All comparison operators apply |
| to strings and numeric types. The operators "==" and "!=" also apply to |
| boolean values, pointer, interface, and channel types. Slice and |
| map types only support testing for equality against the predeclared value |
| "nil". |
| |
| <pre class="grammar"> |
| == equal |
| != not equal |
| < less |
| <= less or equal |
| > greater |
| >= greater or equal |
| </pre> |
| |
| Strings are compared byte-wise (lexically). |
| <p> |
| Booleans are equal if they are either both "true" or both "false". |
| <p> |
| Pointers are equal if they point to the same value. |
| <p> |
| Interface, slice, map, and channel types can be compared for equality according |
| to the rules specified in the section on §Interface types, §Slice types, §Map types, |
| and §Channel types, respectively. |
| |
| |
| <h3>Logical operators</h3> |
| |
| Logical operators apply to boolean operands and yield a boolean result. |
| The right operand is evaluated conditionally. |
| |
| <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> |
| |
| <font color=red>TODO: Need to talk about unary "*", clean up section below.</font> |
| <p> |
| <font color=red>TODO: This text needs to be cleaned up and go elsewhere, there are no address |
| operators involved. |
| </font> |
| <p> |
| Methods are a form of function, and a method ``value'' has a function type. |
| Consider the type T with method M: |
| |
| <pre> |
| type T struct { |
| a int; |
| } |
| func (tp *T) M(a int) int; |
| var t *T; |
| </pre> |
| |
| To construct the value of method M, one writes |
| |
| <pre> |
| t.M |
| </pre> |
| |
| 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> |
| |
| The expression t.M is a function value with type |
| |
| <pre> |
| func (t *T, a int) int |
| </pre> |
| |
| and may be invoked only as a function, not as a method: |
| |
| <pre> |
| var f func (t *T, a int) int; |
| f = t.M; |
| x := f(t, 7); |
| </pre> |
| |
| Note that one does not write t.f(7); taking the value of a method demotes |
| it to a function. |
| |
| In general, given type T with method M and variable t of type T, |
| the method invocation |
| |
| <pre> |
| t.M(args) |
| </pre> |
| |
| is equivalent to the function call |
| |
| <pre> |
| (t.M)(t, args) |
| </pre> |
| |
| <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> |
| 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 |
| |
| <pre> |
| var t1 *T1; |
| var t2 *T2; |
| var i I = t1; |
| m := i.M; |
| m(t2, 7); |
| </pre> |
| |
| will invoke t2.M() even though m was constructed with an expression involving |
| t1. Effectively, the value of m is a function literal |
| |
| <pre> |
| func (recv I, a int) { |
| recv.M(a); |
| } |
| </pre> |
| |
| that is automatically created. |
| <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> |
| |
| <h3>Communication operators</h3> |
| |
| The syntax presented above covers communication operations. This |
| section describes their form and function. |
| <p> |
| Here the term "channel" means "variable of type chan". |
| <p> |
| The built-in function "make" makes a new channel value: |
| |
| <pre> |
| ch := make(chan int) |
| </pre> |
| |
| An optional argument to "make()" specifies a buffer size for an |
| asynchronous channel; if absent or zero, the channel is synchronous: |
| |
| <pre> |
| sync_chan := make(chan int) |
| buffered_chan := make(chan int, 10) |
| </pre> |
| |
| The send operation uses the binary operator "<-", which operates on |
| a channel and a value (expression): |
| |
| <pre> |
| ch <- 3 |
| </pre> |
| |
| In this form, the send operation is an (expression) statement that |
| 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. |
| <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. These two examples are equivalent: |
| |
| <pre> |
| ok := ch <- 3; |
| if ok { print("sent") } else { print("not sent") } |
| |
| if ch <- 3 { print("sent") } else { print("not sent") } |
| </pre> |
| |
| 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> |
| <font color=red> |
| TODO: Adjust the above depending on how we rule on the ok semantics. |
| For instance, does the sent expression get evaluated if ok is false? |
| </font> |
| <p> |
| The receive operation uses the prefix unary operator "<-". |
| The value of the expression is the value received: |
| |
| <pre> |
| <-ch |
| </pre> |
| |
| The expression blocks until a value is available, which then can |
| be assigned to a variable or used like any other expression: |
| |
| <pre> |
| v1 := <-ch |
| v2 = <-ch |
| f(<-ch) |
| </pre> |
| |
| If the receive expression does not save the value, the value is |
| discarded: |
| |
| <pre> |
| <-strobe // wait until clock pulse |
| </pre> |
| |
| If a receive expression is used in a tuple assignment of the form |
| |
| <pre> |
| x, ok = <-ch; // or: x, ok := <-ch |
| </pre> |
| |
| the receive operation becomes non-blocking, and the boolean variable |
| "ok" will be set to "true" if the receive operation succeeded, and set |
| to "false" otherwise. |
| |
| |
| <h3>Constant expressions</h3> |
| |
| A constant expression is an expression whose operands are all constants |
| (§Constants). Additionally, the result of the predeclared functions |
| below (with appropriate arguments) is also constant: |
| |
| <pre> |
| len(a) if a is an array (as opposed to an array slice) |
| </pre> |
| |
| <font color=red> |
| TODO: Complete this list as needed. |
| </font> |
| <p> |
| Constant expressions can be evaluated at compile time. |
| |
| <hr/> |
| |
| <h2>Statements</h2> |
| |
| Statements control execution. |
| |
| <pre class="grammar"> |
| Statement = |
| Declaration | LabelDecl | EmptyStat | |
| SimpleStat | GoStat | ReturnStat | BreakStat | ContinueStat | GotoStat | |
| FallthroughStat | Block | IfStat | SwitchStat | SelectStat | ForStat | |
| DeferStat . |
| |
| SimpleStat = |
| ExpressionStat | IncDecStat | Assignment | SimpleVarDecl . |
| </pre> |
| |
| |
| Statements in a statement list are separated by semicolons, which can be |
| omitted in some cases as expressed by the OptSemicolon production. |
| |
| <pre class="grammar"> |
| StatementList = Statement { OptSemicolon Statement } . |
| </pre> |
| |
| <p> |
| A semicolon may be omitted immediately following: |
| </p> |
| <ul> |
| <li>a closing parenthesis ")" ending a list of declarations (§Declarations and scope rules) |
| <li>a closing brace "}" ending a type declaration (§Type declarations) |
| <li>a closing brace "}" ending a block (including switch and select statements) |
| <li>a label declaration (§Label declarations) |
| </ul> |
| |
| In all other cases a semicolon is required to separate two statements. Since there |
| is an empty statement, a statement list can always be ``terminated'' with a semicolon. |
| |
| |
| <h3>Empty statements</h3> |
| |
| The empty statement does nothing. |
| |
| <pre class="grammar"> |
| EmptyStat = . |
| </pre> |
| |
| |
| <h3>Expression statements</h3> |
| |
| <pre class="grammar"> |
| ExpressionStat = Expression . |
| </pre> |
| |
| <pre> |
| f(x+y) |
| </pre> |
| |
| <font color=red> |
| TODO: specify restrictions. 6g only appears to allow calls here. |
| </font> |
| |
| |
| <h3>IncDec statements</h3> |
| |
| The "++" and "--" statements increment or decrement their operands |
| by the (ideal) constant value 1. |
| |
| <pre class="grammar"> |
| IncDecStat = Expression ( "++" | "--" ) . |
| </pre> |
| |
| The following assignment statements (§Assignments) are semantically |
| equivalent: |
| |
| <pre class="grammar"> |
| IncDec statement Assignment |
| x++ x += 1 |
| x-- x -= 1 |
| </pre> |
| |
| Both operators apply to integer and floating point types only. |
| <p> |
| Note that increment and decrement are statements, not expressions. |
| For instance, "x++" cannot be used as an operand in an expression. |
| |
| |
| <h3>Assignments</h3> |
| |
| <pre class="grammar"> |
| Assignment = ExpressionList assign_op ExpressionList . |
| |
| assign_op = [ add_op | mul_op ] "=" . |
| </pre> |
| |
| The left-hand side must be an l-value such as a variable, pointer indirection, |
| or an array index. |
| |
| <pre> |
| x = 1 |
| *p = f() |
| a[i] = 23 |
| k = <-ch |
| </pre> |
| |
| As in C, arithmetic binary operators can be combined with assignments: |
| |
| <pre> |
| j <<= 2 |
| </pre> |
| |
| A tuple assignment assigns the individual elements of a multi-valued operation, |
| such as function evaluation or some channel and map operations, into individual |
| variables. For instance, a tuple assignment such as |
| |
| <pre> |
| v1, v2, v3 = e1, e2, e3 |
| </pre> |
| |
| assigns the expressions e1, e2, e3 to temporaries and then assigns the temporaries |
| to the variables v1, v2, v3. Thus |
| |
| <pre> |
| a, b = b, a |
| </pre> |
| |
| exchanges the values of a and b. The tuple assignment |
| |
| <pre> |
| x, y = f() |
| </pre> |
| |
| calls the function f, which must return two values, and assigns them to x and y. |
| As a special case, retrieving a value from a map, when written as a two-element |
| tuple assignment, assign a value and a boolean. If the value is present in the map, |
| the value is assigned and the second, boolean variable is set to true. Otherwise, |
| the variable is unchanged, and the boolean value is set to false. |
| |
| <pre> |
| value, present = map_var[key] |
| </pre> |
| |
| To delete a value from a map, use a tuple assignment with the map on the left |
| and a false boolean expression as the second expression on the right, such |
| as: |
| |
| <pre> |
| map_var[key] = value, false |
| </pre> |
| |
| In assignments, the type of the expression must match the type of the left-hand side. |
| |
| |
| <h3>If statements</h3> |
| |
| If statements specify the conditional execution of two branches; the "if" |
| and the "else" branch. If Expression evaluates to true, |
| the "if" branch is executed. Otherwise the "else" branch is executed if present. |
| If Condition is omitted, it is equivalent to true. |
| |
| <pre class="grammar"> |
| IfStat = "if" [ [ SimpleStat ] ";" ] [ Expression ] Block [ "else" Statement ] . |
| </pre> |
| |
| <pre> |
| if x > 0 { |
| return true; |
| } |
| </pre> |
| |
| An "if" statement may include the declaration of a single temporary variable. |
| The scope of the declared variable extends to the end of the if statement, and |
| the variable is initialized once before the statement is entered. |
| |
| <pre> |
| if x := f(); x < y { |
| return x; |
| } else if x > z { |
| return z; |
| } else { |
| return y; |
| } |
| </pre> |
| |
| |
| <!-- |
| TODO: gri thinks that Statement needs to be changed as follows: |
| |
| IfStat = |
| "if" [ [ SimpleStat ] ";" ] [ Expression ] Block |
| [ "else" ( IfStat | Block ) ] . |
| |
| To facilitate the "if else if" code pattern, if the "else" branch is |
| simply another "if" statement, that "if" statement may be written |
| without the surrounding Block: |
| |
| if x > 0 { |
| return 0; |
| } else if x > 10 { |
| return 1; |
| } else { |
| return 2; |
| } |
| |
| --> |
| |
| <h3>Switch statements</h3> |
| |
| Switches provide multi-way execution. |
| |
| <pre class="grammar"> |
| SwitchStat = "switch" [ [ SimpleStat ] ";" ] [ Expression ] "{" { CaseClause } "}" . |
| CaseClause = SwitchCase ":" [ StatementList ] . |
| SwitchCase = "case" ExpressionList | "default" . |
| </pre> |
| |
| There can be at most one default case in a switch statement. In a case clause, |
| the last statement only may be a fallthrough statement ($Fallthrough statement). |
| It indicates that the control should flow from the end of this case clause to |
| the first statement of the next clause. |
| <p> |
| Each case clause effectively acts as a block for scoping purposes |
| ($Declarations and scope rules). |
| <p> |
| The expressions do not need to be constants. They will |
| be evaluated top to bottom until the first successful non-default case is reached. |
| If none matches and there is a default case, the statements of the default |
| case are executed. |
| |
| <pre> |
| switch tag { |
| default: s3() |
| case 0, 1: s1() |
| case 2: s2() |
| } |
| </pre> |
| |
| A switch statement may include the declaration of a single temporary variable. |
| The scope of the declared variable extends to the end of the switch statement, and |
| the variable is initialized once before the switch is entered. |
| |
| <pre> |
| switch x := f(); true { |
| case x < 0: return -x |
| default: return x |
| } |
| </pre> |
| |
| Cases do not fall through unless explicitly marked with a "fallthrough" statement. |
| |
| <pre> |
| switch a { |
| case 1: |
| b(); |
| fallthrough |
| case 2: |
| c(); |
| } |
| </pre> |
| |
| If the expression is omitted, it is equivalent to "true". |
| |
| <pre> |
| switch { |
| case x < y: f1(); |
| case x < z: f2(); |
| case x == 4: f3(); |
| } |
| </pre> |
| |
| |
| <h3>For statements</h3> |
| |
| A for statement specifies repeated execution of a block. The iteration is |
| controlled by a condition, a for clause, or a range clause. |
| |
| <pre class="grammar"> |
| ForStat = "for" [ Condition | ForClause | RangeClause ] Block . |
| Condition = Expression . |
| </pre> |
| |
| In its simplest form, a for statement specifies the repeated execution of |
| a block as long as a condition evaluates to true. The condition is evaluated |
| before each iteration. The type of the condition expression must be boolean. |
| If the condition is absent, it is equivalent to "true". |
| |
| <pre> |
| for a < b { |
| a *= 2 |
| } |
| </pre> |
| |
| A for statement with a for clause is also controlled by its condition, but |
| additionally it may specify an init and post statement, such as an assignment, |
| an increment or decrement statement. The init statement may also be a (simple) |
| variable declaration; no variables can be declared in the post statement. |
| |
| <pre class="grammar"> |
| ForClause = [ InitStat ] ";" [ Condition ] ";" [ PostStat ] . |
| InitStat = SimpleStat . |
| PostStat = SimpleStat . |
| </pre> |
| |
| For instance, one may declare an iteration variable in the init statement: |
| |
| <pre> |
| for i := 0; i < 10; i++ { |
| f(i) |
| } |
| </pre> |
| |
| If present, the init statement is executed once before commencing the iteration; |
| the post statement is executed after each execution of the statement block (and |
| only if the block was executed). The scope of any variable declared in the init |
| statement ends with the end of the for statement block ($Declarations and scope |
| rules, Rule 3). |
| <p> |
| The init and post statement as well as the condition may be omitted; however |
| if either the init or post statement are present, the separating semicolons |
| must be present. If the condition is absent, it is equivalent to "true". |
| The following statements are equivalent: |
| |
| <pre> |
| for ; cond ; { S() } is the same as for cond { S() } |
| for true { S() } is the same as for { S() } |
| </pre> |
| |
| Alternatively, a for statement may be controlled by a range clause. A |
| range clause specifies iteration through all entries of an array 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. Iteration terminates |
| when all entries have been processed, or if the for statement is terminated |
| early, for instance by a break or return statement. |
| |
| <pre class="grammar"> |
| RangeClause = IdentifierList ( "=" | ":=" ) "range" Expression . |
| </pre> |
| |
| The type of the right-hand expression in the range clause must be an array or |
| map, or a pointer to an array or map. If it is a pointer, it must not be nil. |
| The left-hand identifier list must contain one or two identifiers denoting the |
| iteration variables. The first variable is set to the current array 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 index (int) and element, |
| or of the map key and value respectively, must be assignment-compatible to |
| the iteration variables. |
| <p> |
| The iteration variables may be declared by the range clause (":="), in which |
| case their scope ends at the end of the for statement block ($Declarations and |
| scope rules, Rule 3). In this case their types are the array index and element, |
| or the map key and value types, respectively. |
| |
| <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> |
| |
| 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. Likewise, if the range expression is a |
| pointer variable, the behavior of assigning to that variable is implementation- |
| dependent. Assigning to the iteration variables during iteration simply changes |
| the values of those variables for the current iteration; it does not affect any |
| subsequent iterations. |
| |
| |
| <h3>Go statements</h3> |
| |
| A go statement starts the execution of a function as an independent |
| concurrent thread of control within the same address space. The expression |
| must be a function or method call. |
| |
| <pre class="grammar"> |
| GoStat = "go" Expression . |
| </pre> |
| |
| Unlike with a regular function call, program execution does not wait |
| for the invoked function to complete. |
| |
| <pre> |
| go Server() |
| go func(ch chan <- bool) { for { sleep(10); ch <- true; }} (c) |
| </pre> |
| |
| |
| <h3>Select statements</h3> |
| |
| 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. |
| |
| <pre class="grammar"> |
| SelectStat = "select" "{" { CommClause } "}" . |
| CommClause = CommCase ":" [ StatementList ] . |
| CommCase = "case" ( SendExpr | RecvExpr) | "default" . |
| SendExpr = Expression "<-" Expression . |
| RecvExpr = [ Expression ( "=" | ":=" ) ] "<-" Expression . |
| </pre> |
| |
| Each communication clause acts as a block for the purpose of scoping |
| (§Declarations and scope rules). |
| <p> |
| For all the send and receive expressions in the select |
| statement, the channel expression is evaluated. Any values |
| 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 nil, which is equivalent to that case not |
| being present in the select statement. |
| <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. |
| <p> |
| If the channel sends or receives an interface type, its |
| communication can proceed only if the type of the communication |
| clause matches that of the dynamic value to be exchanged. |
| <p> |
| If multiple cases can proceed, a uniform fair choice is made regarding |
| which single communication will execute. |
| <p> |
| The receive case may declare a new variable (via a ":=" assignment). The |
| scope of such variables begins immediately after the variable identifier |
| and ends at the end of the respective "select" case (that is, before the |
| next "case", "default", or closing brace). |
| |
| <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: |
| } |
| } |
| |
| var ca chan interface {}; |
| var i int; |
| var f float; |
| select { |
| case i = <-ca: |
| print("received int ", i, " from ca\n"); |
| case f = <-ca: |
| print("received float ", f, " from ca\n"); |
| } |
| </pre> |
| |
| <font color=red> |
| TODO: Make semantics more precise. |
| </font> |
| |
| |
| <h3>Return statements</h3> |
| |
| A return statement terminates execution of the containing function |
| and optionally provides a result value or values to the caller. |
| |
| <pre class="grammar"> |
| ReturnStat = "return" [ ExpressionList ] . |
| </pre> |
| |
| |
| There are two ways to return values from a function. The first is to |
| explicitly list the return value or values in the return statement: |
| |
| <pre> |
| func simple_f() int { |
| return 2; |
| } |
| </pre> |
| |
| A function may return multiple values. |
| The syntax of the return clause in that case is the same as |
| that of a parameter list; in particular, names must be provided for |
| the elements of the return value. |
| |
| <pre> |
| func complex_f1() (re float, im float) { |
| return -7.0, -4.0; |
| } |
| </pre> |
| |
| A second method to return values |
| is to use those names within the function as variables |
| to be assigned explicitly; the return statement will then provide no |
| values: |
| |
| <pre> |
| func complex_f2() (re float, im float) { |
| re = 7.0; |
| im = 4.0; |
| return; |
| } |
| </pre> |
| |
| |
| <h3>Break statements</h3> |
| |
| Within a for, switch, or select statement, a break statement terminates |
| execution of the innermost such statement. |
| |
| <pre class="grammar"> |
| BreakStat = "break" [ identifier ]. |
| </pre> |
| |
| If there is an identifier, it must be a label marking an enclosing |
| for, switch, or select statement, and that is the one whose execution |
| terminates. |
| |
| <pre> |
| L: for i < n { |
| switch i { |
| case 5: break L |
| } |
| } |
| </pre> |
| |
| |
| <h3>Continue statements</h3> |
| |
| Within a for loop a continue statement begins the next iteration of the |
| loop at the post statement. |
| |
| <pre class="grammar"> |
| ContinueStat = "continue" [ identifier ]. |
| </pre> |
| |
| The optional identifier is analogous to that of a break statement. |
| |
| |
| <h3>Label declarations</h3> |
| |
| A label declaration serves as the target of a goto, break or continue statement. |
| |
| <pre class="grammar"> |
| LabelDecl = identifier ":" . |
| </pre> |
| |
| Example: |
| |
| <pre> |
| Error: |
| </pre> |
| |
| |
| <h3>Goto statements</h3> |
| |
| A goto statement transfers control to the corresponding label statement. |
| |
| <pre class="grammar"> |
| GotoStat = "goto" identifier . |
| </pre> |
| |
| <pre> |
| goto Error |
| </pre> |
| |
| 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: |
| |
| <pre> |
| goto L; // BAD |
| v := 3; |
| L: |
| </pre> |
| |
| is erroneous because the jump to label L skips the creation of v. |
| |
| |
| <h3>Fallthrough statements</h3> |
| |
| A fallthrough statement transfers control to the first statement of the |
| next case clause in a switch statement (§Switch statements). It may only |
| be used in a switch statement, and only as the last statement in a case |
| clause of the switch statement. |
| |
| <pre class="grammar"> |
| FallthroughStat = "fallthrough" . |
| </pre> |
| |
| |
| <h3>Defer statements</h3> |
| |
| A defer statement invokes a function whose execution is deferred to the moment |
| when the surrounding function returns. |
| |
| <pre class="grammar"> |
| DeferStat = "defer" Expression . |
| </pre> |
| |
| 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. |
| |
| <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>Function declarations</h2> |
| |
| A function declaration binds an identifier to a function. |
| Functions contain declarations and statements. They may be |
| recursive. Except for forward declarations (see below), the parameter |
| and result types of the signature must all be complete types (§Type declarations). |
| |
| <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> |
| |
| A function declaration without a block serves as a forward declaration: |
| |
| <pre> |
| func MakeNode(left, right *Node) *Node |
| </pre> |
| |
| |
| Implementation restrictions: Functions can only be declared at the global level. |
| A function must be declared or forward-declared before it can be invoked. |
| |
| |
| <h3>Method declarations</h3> |
| |
| A method declaration is a function declaration with a receiver. The receiver |
| is the first parameter of the method, and the receiver type must be specified |
| as a type name, or as a pointer to a type name. The type specified by the |
| type name is called ``receiver base type''. The receiver base type must be a |
| type declared in the current file, and it must not be a pointer type. |
| The method is said to be ``bound'' to the receiver base type; specifically |
| it is declared within the scope of that type (§Type declarations). If the |
| receiver value is not needed inside the method, its identifier may be omitted |
| in the declaration. |
| |
| <pre class="grammar"> |
| MethodDecl = "func" Receiver identifier Signature [ Block ] . |
| Receiver = "(" [ identifier ] [ "*" ] TypeName ")" . |
| </pre> |
| |
| All methods bound to a receiver base type must have the same receiver type: |
| Either all receiver types are pointers to the base type or they are the base |
| type. <font color=red> |
| (TODO: This restriction can be relaxed at the cost of more complicated |
| assignment rules to interface types). |
| </font> |
| |
| For instance, given type Point, the declarations |
| |
| <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> |
| |
| bind the methods "Length" and "Scale" to the receiver base type "Point". |
| |
| Method declarations may appear anywhere after the declaration of the receiver |
| base type and may be forward-declared. |
| |
| |
| <h3>Predeclared functions</h3> |
| <ul> |
| <li>cap |
| <li>convert |
| <li>len |
| <li>make |
| <li>new |
| <li>panic |
| <li>panicln |
| <li>print |
| <li>println |
| <li>typeof |
| </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> |
| |
| <font color=red> |
| TODO: confirm len() and cap() for channels |
| </font> |
| |
| <p> |
| The type of the result is always "int" and the implementation guarantees that |
| the result always fits into an "int". |
| <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 "s", |
| at any time the following relationship holds: |
| |
| <pre> |
| 0 <= len(s) <= cap(s) |
| </pre> |
| |
| |
| <h3>Conversions</h3> |
| |
| Conversions syntactically look like function calls of the form |
| |
| <pre class="grammar"> |
| T(value) |
| </pre> |
| |
| where "T" is the type name of an arithmetic type or string (§Basic types), |
| and "value" is the value of an expression which can be converted to a value |
| of result type "T". |
| <p> |
| The following conversion rules apply: |
| <p> |
| 1) 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, uint32(int8(0xFF)) is 0xFFFFFFFF. The conversion always |
| yields a valid value; there is no signal for overflow. |
| <p> |
| 2) 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> |
| <p> |
| 3) Strings permit two special conversions. |
| <p> |
| 3a) Converting an integer value yields a string containing the UTF-8 |
| representation of the integer. |
| |
| <pre> |
| string(0x65e5) // "\u65e5" |
| </pre> |
| |
| 3b) Converting an array of uint8s yields a string whose successive |
| bytes are those of the array. (Recall byte is a synonym for uint8.) |
| |
| <pre> |
| string([]byte('h', 'e', 'l', 'l', 'o')) // "hello" |
| </pre> |
| |
| There is no linguistic mechanism to convert between pointers |
| and integers. A library may be provided under restricted circumstances |
| to acccess this conversion in low-level code. |
| <p> |
| <font color=red> |
| TODO: Do we allow interface/ptr conversions in this form or do they |
| have to be written as type guards? (§Type guards) |
| </font> |
| |
| |
| <h3>Allocation</h3> |
| |
| The built-in function "new" takes a type "T" and returns a value of type "*T". |
| The memory is initialized as described in the section on initial values |
| (§Program initialization and execution). |
| |
| <pre> |
| new(T) |
| </pre> |
| |
| For instance |
| |
| <pre> |
| type S struct { a int; b float } |
| new(S) |
| </pre> |
| |
| dynamically allocates memory for a variable of type S, initializes it |
| (a=0, b=0.0), and returns a value of type *S pointing to that variable. |
| |
| <p> |
| <font color=red> |
| TODO Once this has become clearer, connect new() and make() (new() may be |
| explained by make() and vice versa). |
| </font> |
| |
| <h3>Making slices, maps, and channels</h3> |
| |
| The built-in function "make" takes a type "T", optionally followed by a |
| type-specific list of expressions. It returns a value of type "T". "T" |
| must be a slice, map, or channel type. |
| The memory is initialized as described in the section on initial values |
| (§Program initialization and execution). |
| |
| <pre> |
| make(T [, optional list of expressions]) |
| </pre> |
| |
| For instance |
| |
| <pre> |
| make(map[string] int) |
| </pre> |
| |
| creates a new map value and initializes it to an empty map. |
| |
| The only defined parameters affect sizes for allocating slices, maps, and |
| buffered channels: |
| |
| <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> |
| |
| <font color=red> |
| TODO Once this has become clearer, connect new() and make() (new() may be |
| explained by make() and vice versa). |
| </font> |
| |
| <hr/> |
| |
| <h2>Packages</h2> |
| |
| A package is a package clause, optionally followed by import declarations, |
| followed by a series of declarations. |
| |
| <pre class="grammar"> |
| Package = PackageClause { ImportDecl [ ";" ] } { Declaration [ ";" ] } . |
| </pre> |
| |
| The source text following the package clause acts like a block for scoping |
| purposes ($Declarations and scope rules). |
| <p> |
| Every source file identifies the package to which it belongs. |
| The file must begin with a package clause. |
| |
| <pre class="grammar"> |
| PackageClause = "package" PackageName . |
| |
| package Math |
| </pre> |
| |
| |
| A package can gain access to exported identifiers from another package |
| through an import declaration: |
| |
| <pre class="grammar"> |
| ImportDecl = "import" ( ImportSpec | "(" [ ImportSpecList ] ")" ) . |
| ImportSpecList = ImportSpec { ";" ImportSpec } [ ";" ] . |
| ImportSpec = [ "." | PackageName ] PackageFileName . |
| PackageFileName = StringLit . |
| </pre> |
| |
| An import statement makes the exported top-level identifiers of the named |
| package file accessible to this package. |
| <p> |
| In the following discussion, assume we have a package in the |
| file "/lib/math", called package "math", which exports the identifiers |
| "Sin" and "Cos" denoting the respective trigonometric functions. |
| <p> |
| In the general form, with an explicit package name, the import |
| statement declares that package name as an identifier whose |
| contents are the exported elements of the imported package. |
| For instance, after |
| |
| <pre> |
| import M "/lib/math" |
| </pre> |
| |
| the contents of the package /lib/math can be accessed by |
| "M.Sin", "M.Cos", etc. |
| <p> |
| In its simplest form, with no package name, the import statement |
| implicitly uses the imported package name itself as the local |
| package name. After |
| |
| <pre> |
| import "/lib/math" |
| </pre> |
| |
| the contents are accessible by "math.Sin", "math.Cos". |
| <p> |
| Finally, if instead of a package name the import statement uses |
| an explicit period, the contents of the imported package are added |
| to the current package. After |
| |
| <pre> |
| import . "/lib/math" |
| </pre> |
| |
| the contents are accessible by "Sin" and "Cos". In this instance, it is |
| an error if the import introduces name conflicts. |
| <p> |
| Here is a complete example Go package that implements a concurrent prime sieve: |
| |
| <pre> |
| package main |
| |
| // 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(in chan <- int, out *<-chan int, prime int) { |
| for { |
| i := <-in; // Receive value of new variable 'i' from 'in'. |
| if i % prime != 0 { |
| out <- i // Send 'i' to channel 'out'. |
| } |
| } |
| } |
| |
| // 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; |
| 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> |
| |
| When memory is allocated to store a value, either through a declaration |
| or "new()", and no explicit initialization is provided, the memory is |
| given a default initialization. Each element of such a value is |
| set to the ``zero'' for that type: "false" for booleans, "0" for integers, |
| "0.0" for floats, '''' for strings, and "nil" for pointers and interfaces. |
| This initialization is done recursively, so for instance each element of an |
| array of integers will be set to 0 if no other value is specified. |
| <p> |
| These two simple declarations are equivalent: |
| |
| <pre> |
| var i int; |
| var i int = 0; |
| </pre> |
| |
| After |
| |
| <pre> |
| type T struct { i int; f float; next *T }; |
| t := new(T); |
| </pre> |
| |
| the following holds: |
| |
| <pre> |
| t.i == 0 |
| t.f == 0.0 |
| t.next == nil |
| </pre> |
| |
| |
| A package with no imports is initialized by assigning initial values to |
| all its global variables in declaration order and then calling any init() |
| functions defined in its source. Since a package may contain more |
| than one source file, there may be more than one init() function, but |
| only one per source file. |
| <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 |
| thread of execution. |
| <p> |
| Furthermore, an "init()" function cannot be referred to from anywhere |
| in a program. In particular, "init()" cannot be called explicitly, nor |
| can a pointer to "init" be assigned to a function variable). |
| <p> |
| If a package has imports, the imported packages are initialized |
| before initializing the package itself. If multiple packages import |
| a package P, P will be initialized only once. |
| <p> |
| The importing of packages, by construction, guarantees that there can |
| be no cyclic dependencies in initialization. |
| <p> |
| A complete program, possibly created by linking multiple packages, |
| must have one package called main, with a function |
| |
| <pre> |
| func main() { ... } |
| </pre> |
| |
| defined. The function main.main() takes no arguments and returns no |
| value. |
| <p> |
| Program execution begins by initializing the main package and then |
| invoking main.main(). |
| <p> |
| When main.main() returns, the program exits. |
| |
| <hr/> |
| |
| <h2>Systems considerations</h2> |
| |
| <h3>Package unsafe</h3> |
| |
| The built-in package "unsafe", known to the compiler, provides facilities |
| for low-level programming including operations that violate the Go type |
| system. A package using "unsafe" must be vetted manually for type safety. |
| <p> |
| The package "unsafe" provides (at least) the following package interface: |
| |
| <pre class="grammar"> |
| package unsafe |
| |
| const Maxalign int |
| |
| type Pointer *any |
| |
| func Alignof(variable any) int |
| func Offsetof(selector any) int |
| func Sizeof(variable any) int |
| </pre> |
| |
| The pseudo type "any" stands for any Go type; "any" is not a type generally |
| available in Go programs. |
| <p> |
| Any pointer type as well as values of type "uintptr" can be converted into |
| an "unsafe.Pointer" and vice versa. |
| <p> |
| The function "Sizeof" takes an expression denoting a variable of any type |
| and returns the size of the variable in bytes. |
| <p> |
| The function "Offsetof" takes a selector (§Selectors) denoting a struct |
| field of any type and returns the field offset in bytes relative to the |
| struct address. Specifically, the following condition is satisfied for |
| a struct "s" with field "f": |
| |
| <pre> |
| uintptr(unsafe.Pointer(&s)) + uintptr(unsafe.Offsetof(s.f)) == |
| uintptr(unsafe.Pointer(&s.f)) |
| </pre> |
| |
| Computer architectures may impose restrictions on the memory addresses accessed |
| directly by machine instructions. A common such restriction is the requirement |
| for such addresses to be ``aligned''; that is, addresses must be a multiple |
| of a factor, the ``alignment''. The alignment depends on the type of datum |
| accessed. |
| <p> |
| The function "Alignof" takes an expression denoting a variable of any type |
| and returns the alignment of the variable in bytes. The following alignment |
| condition is satisfied for a variable "x": |
| |
| <pre> |
| uintptr(unsafe.Pointer(&x)) % uintptr(unsafe.Alignof(x)) == 0 |
| </pre> |
| |
| The maximum alignment is given by the constant "unsafe.Maxalign". |
| It usually corresponds to the value of "unsafe.Sizeof(x)" for |
| a variable "x" of the largest arithmetic type (8 for a float64), but may |
| be smaller on systems that have less stringent alignment restrictions |
| or are space constrained. |
| <p> |
| The results of calls to "unsafe.Alignof", "unsafe.Offsetof", and |
| "unsafe.Sizeof" are compile-time constants. |
| |
| |
| <h3>Size and alignment guarantees</h3> |
| |
| For the arithmetic types (§Arithmetic types), a Go compiler guarantees the |
| following sizes: |
| |
| <pre class="grammar"> |
| type size in bytes |
| |
| byte, uint8, int8 1 |
| uint16, int16 2 |
| uint32, int32, float32 4 |
| uint64, int64, float64 8 |
| </pre> |
| |
| <p> |
| A Go compiler guarantees the following minimal alignment properties: |
| </p> |
| <ol> |
| <li>For a variable "x" of any type: "1 <= unsafe.Alignof(x) <= unsafe.Maxalign". |
| |
| <li>For a variable "x" of arithmetic type: "unsafe.Alignof(x)" is the smaller |
| of "unsafe.Sizeof(x)" and "unsafe.Maxalign", but at least 1. |
| |
| <li>For a variable "x" of struct type: "unsafe.Alignof(x)" is the largest of |
| all the values "unsafe.Alignof(x.f)" for each field "f" of x, but at least 1. |
| |
| <li>For a variable "x" of array type: "unsafe.Alignof(x)" is the same as |
| unsafe.Alignof(x[0]), but at least 1. |
| </ol> |
| |
| <hr/> |
| |
| <h2><font color=red>Differences between this doc and implementation - TODO</font></h2> |
| <p> |
| <font color=red> |
| Current implementation accepts only ASCII digits for digits; doc says Unicode. |
| <br> |
| </font> |
| </p> |
| |
| </div> |
| </body> |
| </html> |