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