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
|
|
|
[ ] Conversions:
|
|
|
|
- current situation is messy
|
|
|
|
- 2 (3?) different notations for the same thing
|
|
|
|
- unclear when a type guard is needed
|
|
|
|
- unclear where conversions can be applied
|
|
|
|
- for type T int; can we say T(3.0) ?
|
|
|
|
- do we need channel conversion (channel direction)
|
|
|
|
[ ] Semantics of type declaration:
|
|
|
|
- creating a new type (status quo), or only a new type name?
|
|
|
|
- also: declaration type T S; strips methods of S. why/why not?
|
|
|
|
|
|
|
|
|
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-02-06 18:01:10 -07:00
|
|
|
[ ] there is some funny-ness regarding ';' and empty statements and label decls
|
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-01-16 16:36:46 -07:00
|
|
|
[ ] need for type switch? (or use type guard with ok in tuple assignment?)
|
2008-10-30 15:50:23 -06:00
|
|
|
[ ] Is . import implemented / do we still need it?
|
2008-10-09 21:05:24 -06:00
|
|
|
[ ] 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
|
2009-02-11 22:57:15 -07:00
|
|
|
a for loop that is following, and can break L be used inside it?
|
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-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-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-10 13:45:44 -06:00
|
|
|
Where possible, recursive productions are used to express evaluation order
|
2009-02-19 18:31:36 -07:00
|
|
|
and operator precedence syntactically.
|
|
|
|
</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">
|
|
|
|
+ & += &= && == != ( )
|
|
|
|
- | -= |= || < <= [ ]
|
|
|
|
* ^ *= ^= <- > >= { }
|
|
|
|
/ << /= <<= ++ = := , ;
|
|
|
|
% >> %= >>= -- ! ... . :
|
|
|
|
</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-20 14:36:14 -07:00
|
|
|
by choosing a large internal representation of such numbers.
|
|
|
|
<br>
|
|
|
|
<font color=red>TODO: This is too vague. It used to say "sufficiently"
|
|
|
|
but that doesn't help. Define a minimum?</font>
|
|
|
|
</p>
|
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
|
|
|
<pre>
|
|
|
|
"Alea iacta est."
|
|
|
|
"Alea " /* The die */ `iacta est` /* is cast */ "."
|
|
|
|
</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-24 16:17:59 -07:00
|
|
|
A type determines a set of values and operations specific to values of that type.
|
|
|
|
A type may be specified by a (possibly qualified (§Qualified identifiers))
|
|
|
|
type name (§Type declarations) or a <i>type literal</i>,
|
|
|
|
which composes a new type in terms of previously declared types.
|
|
|
|
</p>
|
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
|
|
|
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-19 17:49:10 -07:00
|
|
|
<p>
|
2009-02-24 16:17:59 -07:00
|
|
|
TODO: not sure the rest of this section this is needed; it's all covered or should be covered in the sections
|
|
|
|
that follow.
|
|
|
|
</p>
|
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
|
|
|
|
<i>incomplete</i>. Most types are always complete, although their
|
|
|
|
components, such as the base type of a pointer type, may be incomplete.
|
|
|
|
Struct and interface types are incomplete when forward declared
|
|
|
|
(§Forward declarations) and become complete once they are fully
|
|
|
|
declared. (TODO: You had array here - why?)
|
|
|
|
The type of a variable must be complete where the variable is declared.
|
|
|
|
(TODO: would be better to say what you CAN do with an interface type,
|
|
|
|
and then drop all the references to complete types in the sections
|
|
|
|
that follow. What can you do? Use one to declare a pointer variable/field/param.
|
|
|
|
Anything else?)
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
The <i>interface</i> of a type is the set of methods bound to it
|
|
|
|
(§Method declarations); for pointer types, it is the interface
|
|
|
|
of the pointer base type (§Pointer types). All types have an interface;
|
|
|
|
if they have no methods, it is the <i>empty'' interface</i>.
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
The <i>static type</i> (or just <i>type</i>) of a variable is the
|
|
|
|
type defined by its declaration. Variables of interface type
|
|
|
|
(§Interface types) also have a distinct <i>dynamic type</i>, which
|
|
|
|
is the actual type of the value stored in the variable at run-time.
|
|
|
|
The dynamic type may vary during execution but is always compatible
|
|
|
|
with the static type of the interface variable. For non-interfaces
|
|
|
|
types, the dynamic type is always the static type.
|
|
|
|
</p>
|
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>
|
|
|
|
Basic types include traditional arithmetic types, booleans, and strings. All are predeclared.
|
|
|
|
</p>
|
2009-02-23 20:22:05 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<h3>Arithmetic 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-02-24 16:17:59 -07:00
|
|
|
Except for <code>byte</code>, which is an alias for <code>uint8</code>,
|
|
|
|
to avoid portability issues all numeric types are distinct. Conversions
|
|
|
|
are required when different numeric types are mixed in an expression
|
|
|
|
or assignment. For instance, <code>int32</code> and <code>int</code>
|
|
|
|
are not the same type even though they may have the same size on a
|
|
|
|
particular architecture.
|
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>
|
|
|
|
String literals separated only by the empty string, white
|
|
|
|
space, or comments are concatenated into a single string literal.
|
|
|
|
</p>
|
|
|
|
<pre class="grammar">
|
|
|
|
StringLit = string_lit { string_lit } .
|
|
|
|
</pre>
|
2008-12-04 18:33:37 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<h3>Array types</h3>
|
2008-12-04 18:33:37 -07:00
|
|
|
|
2009-02-24 16:17:59 -07:00
|
|
|
<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>
|
2008-12-04 18:33:37 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre class="grammar">
|
|
|
|
ArrayType = "[" ArrayLength "]" ElementType .
|
|
|
|
ArrayLength = Expression .
|
|
|
|
ElementType = CompleteType .
|
|
|
|
</pre>
|
2009-02-19 17:49:10 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<p>
|
2009-02-24 16:17:59 -07:00
|
|
|
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>
|
2008-12-04 18:33:37 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
2009-02-23 20:26:07 -07:00
|
|
|
[32]byte
|
|
|
|
[2*N] struct { x, y int32 }
|
|
|
|
[1000]*float64
|
2009-02-19 17:49:10 -07:00
|
|
|
</pre>
|
2008-12-04 18:33:37 -07:00
|
|
|
|
2008-08-28 18:47:53 -06:00
|
|
|
|
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
|
|
|
|
an identifier and type for each field. Within a struct field identifiers
|
|
|
|
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-02-23 20:26:07 -07:00
|
|
|
StructType = "struct" [ "{" [ FieldDeclList ] "}" ] .
|
|
|
|
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
|
|
|
|
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
|
|
|
|
P.T3; // the field name is the unqualified type name T3
|
|
|
|
*P.T4; // the field name is the unqualified type name T4
|
|
|
|
x, y int;
|
|
|
|
}
|
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 16:17:59 -07:00
|
|
|
// The tag strings contain 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-02-24 16:17:59 -07:00
|
|
|
type, called the ``base type'' of the pointer, and the value <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-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
|
|
|
|
map[string] chan
|
2009-02-19 17:49:10 -07:00
|
|
|
</pre>
|
2009-02-23 20:22:05 -07:00
|
|
|
|
|
|
|
<p>
|
2009-02-24 16:17:59 -07:00
|
|
|
To permit construction of recursive and mutually recursive types,
|
|
|
|
the pointer base type may be denoted by the type name of a
|
|
|
|
forward-declared, incomplete type (§Forward declarations).
|
|
|
|
</p>
|
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-24 16:17:59 -07:00
|
|
|
<p>TODO: stopped fine-grained editing here </p>
|
2009-02-23 20:26:07 -07:00
|
|
|
A function type denotes the set of all functions with the same parameter
|
|
|
|
and result types, and the value "nil".
|
2009-02-23 20:22:05 -07:00
|
|
|
|
|
|
|
<pre class="grammar">
|
2009-02-23 20:26:07 -07:00
|
|
|
FunctionType = "func" Signature .
|
|
|
|
Signature = "(" [ ParameterList ] ")" [ Result ] .
|
|
|
|
ParameterList = ParameterDecl { "," ParameterDecl } .
|
|
|
|
ParameterDecl = [ IdentifierList ] ( Type | "..." ) .
|
|
|
|
Result = Type | "(" ParameterList ")" .
|
2009-02-23 20:22:05 -07:00
|
|
|
</pre>
|
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
In ParameterList, the parameter names (IdentifierList) either must all be
|
|
|
|
present, or all be absent. If the parameters are named, each name stands
|
|
|
|
for one parameter of the specified type. If the parameters are unnamed, each
|
|
|
|
type stands for one parameter of that type.
|
2009-02-23 20:22:05 -07:00
|
|
|
<p>
|
2009-02-23 20:26:07 -07:00
|
|
|
For the last incoming parameter only, instead of a parameter type one
|
|
|
|
may write "...". The ellipsis indicates that the last parameter stands
|
|
|
|
for an arbitrary number of additional arguments of any type (including
|
|
|
|
no additional arguments). If the parameters are named, the identifier
|
|
|
|
list immediately preceding "..." must contain only one identifier (the
|
|
|
|
name of the last parameter).
|
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)
|
|
|
|
</pre>
|
2009-02-23 20:22:05 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
If the result type of a function is itself a function type, the result type
|
|
|
|
must be parenthesized to resolve a parsing ambiguity:
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
func (n int) (func (p* T))
|
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-23 20:26:07 -07:00
|
|
|
Type interfaces may be specified explicitly by interface types.
|
|
|
|
An interface type denotes the set of all types that implement at least
|
|
|
|
the set of methods specified by the interface type, and the value "nil".
|
|
|
|
|
|
|
|
<pre class="grammar">
|
|
|
|
InterfaceType = "interface" [ "{" [ MethodSpecList ] "}" ] .
|
|
|
|
MethodSpecList = MethodSpec { ";" MethodSpec } [ ";" ] .
|
|
|
|
MethodSpec = IdentifierList Signature | TypeName .
|
|
|
|
</pre>
|
2009-02-23 20:22:05 -07:00
|
|
|
|
|
|
|
<pre>
|
2009-02-23 20:26:07 -07:00
|
|
|
// An interface specifying a basic File type.
|
|
|
|
interface {
|
|
|
|
Read, Write (b Buffer) bool;
|
|
|
|
Close ();
|
2009-02-23 20:22:05 -07:00
|
|
|
}
|
|
|
|
</pre>
|
2009-02-23 20:26:07 -07:00
|
|
|
|
|
|
|
Any type (including interface types) whose interface has, possibly as a
|
|
|
|
subset, the complete set of methods of an interface I is said to implement
|
|
|
|
interface I. For instance, if two types S1 and S2 have the methods
|
|
|
|
|
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-23 20:26:07 -07:00
|
|
|
(where T stands for either S1 or S2) then the File interface is
|
|
|
|
implemented by both S1 and S2, regardless of what other methods
|
|
|
|
S1 and S2 may have or share.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
All types implement the empty interface:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
interface {}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
In general, a type implements an arbitrary number of interfaces.
|
|
|
|
For instance, consider the interface
|
|
|
|
|
|
|
|
<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-23 20:26:07 -07:00
|
|
|
If S1 and S2 also implement
|
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>
|
|
|
|
|
|
|
|
they implement the Lock interface as well as the File interface.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2009-02-23 20:26:07 -07:00
|
|
|
An interface may contain a type name T in place of a method specification.
|
|
|
|
T must denote another, complete (and not forward-declared) interface type.
|
|
|
|
Using this notation is equivalent to enumerating the methods of T explicitly
|
|
|
|
in the interface containing T.
|
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
|
|
|
Forward declaration:
|
|
|
|
A interface type consisting of only the reserved word "interface" may be used in
|
|
|
|
a type declaration; it declares an incomplete interface type (§Type declarations).
|
|
|
|
This allows the construction of mutually recursive types such as:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
type T2 interface
|
|
|
|
type T1 interface {
|
|
|
|
foo(T2) int;
|
|
|
|
}
|
|
|
|
type T2 interface {
|
|
|
|
bar(T1) int;
|
|
|
|
}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<h3>Slice types</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
A slice type denotes the set of all slices (segments) of arrays
|
|
|
|
(§Array types) of a given element type, and the value "nil".
|
|
|
|
The number of elements of a slice is called its length; it is never negative.
|
|
|
|
The elements of a slice are designated by indices which are
|
|
|
|
integers from 0 through the length - 1.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre class="grammar">
|
|
|
|
SliceType = "[" "]" ElementType .
|
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
|
|
|
Syntactically and semantically, arrays and slices look and behave very
|
|
|
|
similarly, but with one important difference: A slice is a descriptor
|
|
|
|
of an array segment; in particular, different variables of a slice type may
|
|
|
|
refer to different (and possibly overlapping) segments of the same underlying
|
|
|
|
array. Thus, with respect to the underlying array, slices behave like
|
|
|
|
references. In contrast, two different variables of array type always
|
|
|
|
denote two different arrays.
|
|
|
|
<p>
|
|
|
|
For slices, the actual array underlying the slice may extend past the current
|
|
|
|
slice length; the maximum length a slice may assume is called its capacity.
|
|
|
|
The capacity of any slice "a" can be discovered using the built-in function
|
2008-12-12 11:30:10 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
cap(a)
|
|
|
|
</pre>
|
2008-12-12 11:30:10 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
and the following relationship between "len()" and "cap()" holds:
|
2008-09-11 18:48:20 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
0 <= len(a) <= cap(a)
|
2009-02-19 17:49:10 -07:00
|
|
|
</pre>
|
2008-09-11 18:48:20 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
The value of an uninitialized slice is "nil", and its length and capacity
|
|
|
|
are 0. A new, initialized slice value for a given element type T is
|
|
|
|
made using the built-in function "make", which takes a slice type
|
|
|
|
and parameters specifying the length and optionally the capacity:
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
make([]T, length)
|
|
|
|
make([]T, length, capacity)
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
The "make()" call allocates a new underlying array to which the returned
|
|
|
|
slice value refers. More precisely, calling "make"
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
make([]T, length, capacity)
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
is effectively the same as allocating an array and slicing it
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
new([capacity]T)[0 : length]
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<p>
|
|
|
|
Indexing: Given a (pointer to) a slice variable "a", a slice element is
|
|
|
|
specified with an index operation:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
a[i]
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
This denotes the slice element at index "i". "i" must be within bounds,
|
|
|
|
that is "0 <= i < len(a)".
|
2009-02-19 18:31:36 -07:00
|
|
|
<p>
|
2009-02-23 20:26:07 -07:00
|
|
|
Slicing: Given a a slice variable "a", a sub-slice is created with a slice
|
|
|
|
operation:
|
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[i : j]
|
2009-02-19 17:49:10 -07:00
|
|
|
</pre>
|
2009-02-23 20:26:07 -07:00
|
|
|
|
|
|
|
This creates the sub-slice consisting of the elements "a[i]" through "a[j - 1]"
|
|
|
|
(that is, excluding "a[j]"). The values "i" and "j" must satisfy the condition
|
|
|
|
"0 <= i <= j <= cap(a)". The length of the new slice is "j - i". The capacity of
|
|
|
|
the slice is "cap(a) - i"; thus if "i" is 0, the slice capacity does not change
|
|
|
|
as a result of a slice operation. The type of a sub-slice is the same as the
|
|
|
|
type of the slice. Unlike the capacity, the length of a sub-slice may be larger
|
|
|
|
than the length of the original slice.
|
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-23 20:26:07 -07:00
|
|
|
A map is a composite type consisting of a variable number of entries
|
|
|
|
called (key, value) pairs. For a given map, the keys and values must
|
|
|
|
each be of a specific complete type (§Types) called the key and value type,
|
|
|
|
respectively. The number of entries in a map is called its length; it is never
|
|
|
|
negative.
|
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
|
|
|
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-23 20:26:07 -07:00
|
|
|
The comparison operators "==" and "!=" (§Comparison operators) must be defined
|
|
|
|
for operands of the key type; thus the key type must be a basic, pointer,
|
|
|
|
interface, or channel type. If the key type is an interface type,
|
|
|
|
the dynamic key types must support these comparison operators. In this case,
|
|
|
|
inserting a map value with a key that does not support testing for equality
|
|
|
|
is a run-time error.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2009-02-23 20:26:07 -07:00
|
|
|
Upon creation, a map is empty and values may be added and removed
|
|
|
|
during execution.
|
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-23 20:26:07 -07:00
|
|
|
The length of a map "m" can be discovered using the built-in function
|
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
|
|
|
len(m)
|
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
|
|
|
The value of an uninitialized map is "nil". A new, empty map value for given
|
|
|
|
map type M is made using the built-in function "make" which takes the map type
|
|
|
|
and an optional capacity as arguments:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre>
|
|
|
|
my_map := make(M, 100);
|
|
|
|
</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
|
|
|
The map capacity is an allocation hint for more efficient incremental growth
|
|
|
|
of the map.
|
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
|
|
|
<h3>Channel types</h3>
|
2009-02-19 17:49:10 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
A channel provides a mechanism for two concurrently executing functions
|
|
|
|
to synchronize execution and exchange values of a specified type. This
|
|
|
|
type must be a complete type (§Types). <font color=red>(TODO could it be incomplete?)</font>
|
2009-02-19 17:49:10 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<pre class="grammar">
|
|
|
|
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-23 20:26:07 -07:00
|
|
|
Upon creation, a channel can be used both to send and to receive.
|
|
|
|
By conversion or assignment, a channel may be constrained only to send or
|
|
|
|
to receive. This constraint is called a channel's ``direction''; either
|
|
|
|
bi-directional (unconstrained), send, or receive.
|
2008-09-29 19:41:30 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
2009-02-23 20:26:07 -07:00
|
|
|
chan T // can send and receive values of type T
|
|
|
|
chan <- float // can only be used to send floats
|
|
|
|
<-chan int // can only receive ints
|
2009-02-19 17:49:10 -07:00
|
|
|
</pre>
|
2008-09-29 19:41:30 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
The value of an uninitialized channel is "nil". A new, initialized channel
|
|
|
|
value for a given element type T is made using the built-in function "make",
|
|
|
|
which takes the channel type and an optional capacity as arguments:
|
2008-10-23 13:04:45 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
2009-02-23 20:26:07 -07:00
|
|
|
my_chan = make(chan int, 100);
|
2009-02-19 17:49:10 -07:00
|
|
|
</pre>
|
2008-09-29 19:41:30 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
The capacity sets the size of the buffer in the communication channel. If the
|
|
|
|
capacity is greater than zero, the channel is asynchronous and, provided the
|
|
|
|
buffer is not full, sends can succeed without blocking. If the capacity is zero,
|
|
|
|
the communication succeeds only when both a sender and receiver are ready.
|
2008-10-30 16:52:37 -06:00
|
|
|
|
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<h3>Type equality</h3>
|
|
|
|
|
|
|
|
<p>
|
|
|
|
Types may be ``different'', ``structurally equal'', or ``identical''.
|
|
|
|
Go is a type-safe language; generally different types cannot be mixed
|
|
|
|
in binary operations, and values cannot be assigned to variables of different
|
|
|
|
types. However, values may be assigned to variables of structurally
|
|
|
|
equal types. Finally, type guards succeed only if the dynamic type
|
|
|
|
is identical to or implements the type tested against (§Type guards).
|
|
|
|
<p>
|
|
|
|
Structural type equality (equality for short) is defined by these rules:
|
|
|
|
<p>
|
|
|
|
Two type names denote equal types if the types in the corresponding declarations
|
|
|
|
are equal. Two type literals specify equal types if they have the same
|
|
|
|
literal structure and corresponding components have equal types. Loosely
|
|
|
|
speaking, two types are equal if their values have the same layout in memory.
|
|
|
|
More precisely:
|
|
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>Two array types are equal if they have equal element types and if they
|
|
|
|
have the same array length.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two struct types are equal if they have the same number of fields in the
|
|
|
|
same order, corresponding fields either have both the same name or
|
|
|
|
are both anonymous, and corresponding field types are identical.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two pointer types are equal if they have equal base types.
|
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
|
|
|
|
equal (a "..." parameter is equal to another "..." parameter).
|
|
|
|
Note that parameter and result names do not have to match.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two slice types are equal if they have equal element types.
|
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
|
|
|
|
the same direction.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two map types are equal if they have equal key and value types.
|
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
|
|
|
|
with the same names and equal function types. Note that the order
|
|
|
|
of the methods in the respective type declarations is irrelevant.
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
<p>
|
|
|
|
Type identity is defined by these rules:
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
Two type names denote identical types if they originate in the same
|
|
|
|
type declaration. Two type literals specify identical types if they have the
|
|
|
|
same literal structure and corresponding components have identical types.
|
|
|
|
More precisely:
|
|
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>Two array types are identical if they have identical element types and if
|
|
|
|
they have the same array length.
|
|
|
|
|
|
|
|
<li>Two struct types are identical if they have the same number of fields in
|
|
|
|
the same order, corresponding fields either have both the same name or
|
|
|
|
are both anonymous, and corresponding field types are identical.
|
|
|
|
|
|
|
|
<li>Two pointer types are identical if they have identical base types.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two function types are identical if they have the same number of
|
|
|
|
parameters and result values both with the same (or absent) names, and
|
|
|
|
if corresponding parameter and result types are identical (a "..."
|
|
|
|
parameter is identical to another "..." parameter with the same name).
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two slice types are identical if they have identical element types.
|
2009-01-27 15:51:24 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two channel types are identical if they have identical value types and
|
|
|
|
the same direction.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two map types are identical if they have identical key and value types.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
<li>Two interface types are identical if they have the same set of methods
|
|
|
|
with the same names and identical function types. Note that the order
|
|
|
|
of the methods in the respective type declarations is irrelevant.
|
|
|
|
</ul>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
Note that the type denoted by a type name is identical only to the type literal
|
|
|
|
in the type name's declaration.
|
|
|
|
<p>
|
|
|
|
Finally, two types are different if they are not structurally equal.
|
|
|
|
(By definition, they cannot be identical, either).
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
For instance, given the declarations
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
type (
|
|
|
|
T0 []string;
|
|
|
|
T1 []string
|
|
|
|
T2 struct { a, b int };
|
|
|
|
T3 struct { a, c int };
|
|
|
|
T4 func (int, float) *T0
|
|
|
|
T5 func (x int, y float) *[]string
|
|
|
|
)
|
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
|
|
|
these are some types that are equal
|
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
|
|
|
|
T0 and []string
|
|
|
|
T2 and T3
|
|
|
|
T4 and T5
|
|
|
|
T3 and struct { a int; int }
|
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
|
|
|
and these are some types that are identical
|
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-23 20:26:07 -07:00
|
|
|
As an example, "T0" and "T1" are equal but not identical because they have
|
|
|
|
different declarations.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-24 16:17:59 -07:00
|
|
|
<h3>Assignment compatibility</h3>
|
|
|
|
|
|
|
|
<!--
|
|
|
|
TODO in another round of editing:
|
|
|
|
It may make sense to have a special section in this doc containing these rule
|
|
|
|
sets for:
|
|
|
|
|
|
|
|
complete/incomplete types
|
|
|
|
equality of types
|
|
|
|
identity of types
|
|
|
|
comparisons
|
|
|
|
assignment compatibility
|
|
|
|
-->
|
|
|
|
|
|
|
|
<p>
|
|
|
|
Values of any type may always be assigned to variables
|
|
|
|
of equal static type. Some types and values have conditions under which they may
|
|
|
|
be assigned to different types:
|
|
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
|
|
The predeclared constant <code>nil</code> can be assigned to any
|
|
|
|
pointer, function, slice, map, channel, or interface variable.
|
|
|
|
<li>
|
|
|
|
Arrays can be assigned to slice variables with equal element type.
|
|
|
|
When assigning to a slice variable, the array is not copied but a
|
|
|
|
slice comprising the entire array is created.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
A value can be assigned to an interface variable if the dynamic
|
|
|
|
type of the value implements the interface.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
A value of bidirectional channel type can be assigned to any channel
|
|
|
|
variable of equal channel value type.
|
|
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
<h3>Comparison compatibility</h3>
|
|
|
|
|
|
|
|
<p>
|
|
|
|
Values of any type may be compared to other values of equal static
|
|
|
|
type. Values of numeric and string type may be compared using the
|
|
|
|
full range of comparison operators as described in §Comparison operators;
|
|
|
|
booleans may be compared only for equality or inequality.
|
|
|
|
</p>
|
|
|
|
|
|
|
|
<p>
|
|
|
|
Values of composite type may be
|
|
|
|
compared for equality or inequality using the <code>==</code> and
|
|
|
|
<code>!=</code> operators, with the following provisos:
|
|
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
|
|
Arrays and structs may not be compared to anything.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
A slice value may only be compared explicitly against <code>nil</code>
|
|
|
|
and is equal to <code>nil</code> if it has been assigned the explicit
|
|
|
|
value <code>nil</code> or if it is a variable (or array element,
|
|
|
|
field, etc.) that has not been modified since it was created
|
|
|
|
uninitialized.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Similarly, an interface value is equal to <code>nil</code> if it has
|
|
|
|
been assigned the explicit value <code>nil</code> or if it is a
|
|
|
|
variable (or array element, field, etc.) that has not been modified
|
|
|
|
since it was created uninitialized.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
For types that can be compared to <code>nil</code>,
|
|
|
|
two values of the same type are equal if they both equal <code>nil</code>,
|
|
|
|
unequal if one equals <code>nil</code> and one does not.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Pointer values are equal if they point to the same location.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Function values are equal if they point to the same function.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Channel and map values are equal if they were created by the same call of <code>make</code>
|
|
|
|
(§Making slices, maps, and channels).
|
|
|
|
</li>
|
|
|
|
<li>
|
|
|
|
Interface values are comparison compatible if they have the same static type and
|
|
|
|
equal if they have the same dynamic type.
|
|
|
|
</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-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-02-23 20:26:07 -07:00
|
|
|
<li> The scope of an (identifier denoting a) type, function or package
|
|
|
|
extends from the point of the identifier in the declaration
|
|
|
|
to the end of the innermost surrounding block.</li>
|
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
|
|
|
|
the end of the declaration to the end of the innermost
|
|
|
|
surrounding block. If the variable is declared in the
|
|
|
|
<i>init</i> statement of an <code>if </code>, <code>for</code>,
|
|
|
|
or <code>switch </code> statement, the
|
|
|
|
innermost surrounding block is the block associated
|
|
|
|
with that statement.</li>
|
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-02-23 20:26:07 -07:00
|
|
|
<li> The scope of a label is a unique scope emcompassing
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
cap convert len make new panic panicln print println typeof (TODO: typeof??)
|
2009-02-11 16:09:15 -07:00
|
|
|
|
2009-02-23 20:26:07 -07:00
|
|
|
Packages:
|
|
|
|
sys unsafe (TODO: does sys endure?)
|
2009-02-19 17:49:10 -07:00
|
|
|
</pre>
|
2009-02-11 16:09:15 -07:00
|
|
|
|
2008-10-07 18:14:30 -06: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
|
|
|
|
``ideal integer'' or ``ideal float'' (§Ideal number). If the type
|
|
|
|
is present, all constants take the type specified, and the types
|
|
|
|
of all the expressions must be assignment-compatible
|
|
|
|
with that type.
|
|
|
|
</p>
|
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
|
|
|
|
first preceding non-empty expression list. Omitting the list of
|
|
|
|
expressions is therefore equivalent to repeating the previous list.
|
|
|
|
The number of identifiers must be equal to the number of expressions
|
|
|
|
in the previous list. Together with the <code>iota</code> constant generator
|
|
|
|
(§Iota) this mechanism permits light-weight declaration of sequential values:
|
|
|
|
</p>
|
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 } [ ";" ] .
|
|
|
|
TypeSpec = identifier Type .
|
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-02-23 20:26:07 -07:00
|
|
|
type TreeNode struct {
|
|
|
|
left, right *TreeNode;
|
|
|
|
value Point;
|
|
|
|
}
|
|
|
|
|
|
|
|
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.
|
|
|
|
The variable type must be a complete type (§Types).
|
|
|
|
</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>
|
|
|
|
of the type (§Program initialization and execution).
|
|
|
|
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>
|
|
|
|
count, error := os.Close(fd); // os.Close() returns two values
|
|
|
|
</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-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
|
|
|
|
before the end of the block containing the forward declaration.
|
|
|
|
</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
|
|
|
|
2008-09-11 18:48:20 -06:00
|
|
|
An expression specifies the computation of a value via the application of
|
|
|
|
operators and function invocations on operands. An expression has a value and
|
|
|
|
a type.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-12 13:26:22 -06:00
|
|
|
The type of a constant expression may be an ideal number. The type of such expressions
|
2008-10-16 16:03:22 -06:00
|
|
|
is implicitly converted into the 'expected numeric type' required for the expression.
|
2008-09-11 18:48:20 -06:00
|
|
|
The conversion is legal if the (ideal) expression value is a member of the
|
2008-10-16 16:03:22 -06:00
|
|
|
set represented by the expected numeric type. In all other cases, and specifically
|
|
|
|
if the expected type is not a numeric type, the expression is erroneous.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-16 16:03:22 -06:00
|
|
|
For instance, if the expected numeric type is a uint32, any ideal number
|
|
|
|
which fits into a uint32 without loss of precision can be legally converted.
|
|
|
|
Thus, the values 991, 42.0, and 1e9 are ok, but -1, 3.14, or 1e100 are not.
|
2008-09-11 18:48:20 -06:00
|
|
|
|
2008-10-16 16:03:22 -06:00
|
|
|
<!--
|
2008-09-12 13:26:22 -06:00
|
|
|
TODO(gri) This may be overly constraining. What about "len(a) + c" where
|
|
|
|
c is an ideal number? Is len(a) of type int, or of an ideal number? Probably
|
2009-01-05 12:17:26 -07:00
|
|
|
should be ideal number, because for arrays, it is a constant.
|
2008-10-16 16:03:22 -06:00
|
|
|
-->
|
2008-09-12 13:26:22 -06:00
|
|
|
|
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-19 17:49:10 -07:00
|
|
|
Operand = Literal | QualifiedIdent | "(" Expression ")" .
|
|
|
|
Literal = BasicLit | CompositeLit | FunctionLit .
|
|
|
|
BasicLit = int_lit | float_lit | char_lit | StringLit .
|
|
|
|
StringLit = string_lit { string_lit } .
|
|
|
|
</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
|
|
|
|
|
|
|
An operand is called ``constant'' if it is a literal of a basic type
|
2008-09-30 11:57:59 -06:00
|
|
|
(including the predeclared constants "true" and "false", and the values
|
|
|
|
denoted by "iota"), the predeclared constant "nil", or a parenthesized
|
|
|
|
constant expression (§Constant expressions). Constants have values that
|
|
|
|
are known at compile-time.
|
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
|
|
|
|
2008-11-17 19:11:36 -07:00
|
|
|
A qualified identifier is an identifier qualified by a package name.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
|
|
|
<font color=red>
|
2008-11-17 19:11:36 -07:00
|
|
|
TODO(gri) expand this section.
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
2008-11-17 19:11:36 -07:00
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
QualifiedIdent = { PackageName "." } identifier .
|
|
|
|
PackageName = identifier .
|
|
|
|
</pre>
|
2008-09-11 18:48:20 -06:00
|
|
|
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>Composite literals</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
Literals for composite data structures consist of the type of the value
|
2009-01-07 10:31:35 -07:00
|
|
|
followed by a braced expression list for array, slice, and structure literals,
|
2008-09-03 14:37:44 -06:00
|
|
|
or a list of expression pairs for map literals.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
CompositeLit = LiteralType "(" [ ( ExpressionList | ExprPairList ) [ "," ] ] ")" .
|
|
|
|
LiteralType = Type | "[" "..." "]" ElementType .
|
|
|
|
ExprPairList = ExprPair { "," ExprPair } .
|
|
|
|
ExprPair = Expression ":" Expression .
|
|
|
|
</pre>
|
2008-09-03 14:37:44 -06:00
|
|
|
|
2009-01-07 10:31:35 -07:00
|
|
|
The LiteralType must be an struct, array, slice, or map type.
|
|
|
|
The types of the expressions must match the respective field, element, and
|
|
|
|
key types of the LiteralType; there is no automatic type conversion.
|
2008-10-23 18:19:56 -06:00
|
|
|
Composite literals are values of the type specified by LiteralType; that is
|
|
|
|
a new value is created every time the literal is evaluated. To get
|
2009-02-19 17:49:10 -07:00
|
|
|
a pointer to the literal, the address operator "&" must be used.
|
|
|
|
<p>
|
2008-09-03 14:37:44 -06:00
|
|
|
Given
|
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
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
one can write
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
pi := Num(Rat(22, 7), 3.14159, "pi");
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
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
|
|
|
|
elements are set to the appropriate zero value for the array element type.
|
2009-01-07 10:31:35 -07:00
|
|
|
It is an error to provide more elements than specified in LiteralType. The
|
|
|
|
notation "..." may be used in place of the length expression to denote a
|
|
|
|
length equal to the number of elements in the literal.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
buffer := [10]string(); // len(buffer) == 10
|
|
|
|
primes := [6]int(2, 3, 5, 7, 9, 11); // len(primes) == 6
|
|
|
|
days := [...]string("sat", "sun"); // len(days) == 2
|
|
|
|
</pre>
|
2009-01-07 10:31:35 -07:00
|
|
|
|
|
|
|
A slice literal is a slice describing the entire underlying array literal.
|
|
|
|
Thus, the length and capacity of a slice literal is the number of elements
|
|
|
|
provided in the literal. A slice literal of the form
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
[]T(x1, x2, ... xn)
|
|
|
|
</pre>
|
2009-01-07 10:31:35 -07:00
|
|
|
|
|
|
|
is essentially a shortcut for a slice operation applied to an array literal:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
[n]T(x1, x2, ... xn)[0 : n]
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
Map literals are similar except the elements of the expression list are
|
|
|
|
key-value pairs separated by a colon:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
m := map[string]int("good": 0, "bad": 1, "indifferent": 7);
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<font color=red>
|
2008-09-04 16:17:27 -06:00
|
|
|
TODO: Consider adding helper syntax for nested composites
|
|
|
|
(avoids repeating types but complicates the spec needlessly.)
|
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>Function literals</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-10-07 18:14:30 -06:00
|
|
|
A function literal represents an anonymous function. It consists of a
|
|
|
|
specification of the function type and the function body. The parameter
|
|
|
|
and result types of the function type must all be complete types (§Types).
|
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
|
|
|
FunctionLit = "func" Signature Block .
|
|
|
|
Block = "{" [ StatementList ] "}" .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-30 15:48:29 -07:00
|
|
|
The type of a function literal is the function type specified.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
func (a, b int, z float) bool { return a*b < int(z); }
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-09-08 16:01:04 -06:00
|
|
|
A function literal can be assigned to a variable of the
|
2009-01-30 15:48:29 -07:00
|
|
|
corresponding function type, or invoked directly.
|
2008-09-08 16:01:04 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
f := func(x, y int) int { return x + y; }
|
|
|
|
func(ch chan int) { ch <- ACK; } (reply_chan)
|
|
|
|
</pre>
|
2008-09-08 16:01:04 -06:00
|
|
|
|
2009-02-06 18:01:10 -07:00
|
|
|
Function literals are "closures": they may refer to variables
|
|
|
|
defined in a surrounding function. Those variables are then shared between
|
|
|
|
the surrounding function and the function literal, and they survive as long
|
|
|
|
as they are accessible in any way.
|
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>
|
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
|
|
|
PrimaryExpr =
|
|
|
|
Operand |
|
|
|
|
PrimaryExpr Selector |
|
|
|
|
PrimaryExpr Index |
|
|
|
|
PrimaryExpr Slice |
|
|
|
|
PrimaryExpr TypeGuard |
|
|
|
|
PrimaryExpr Call .
|
|
|
|
|
|
|
|
Selector = "." identifier .
|
|
|
|
Index = "[" Expression "]" .
|
|
|
|
Slice = "[" Expression ":" Expression "]" .
|
|
|
|
TypeGuard = "." "(" Type ")" .
|
|
|
|
Call = "(" [ ExpressionList ] ")" .
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
x
|
|
|
|
2
|
|
|
|
(s + ".txt")
|
|
|
|
f(3.1415, true)
|
|
|
|
Point(1, 2)
|
|
|
|
m["foo"]
|
|
|
|
s[i : j + 1]
|
|
|
|
obj.color
|
|
|
|
Math.sin
|
|
|
|
f.p[i].x()
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Selectors</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-10-09 18:12:09 -06:00
|
|
|
A primary expression of the form
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
x.f
|
|
|
|
</pre>
|
2008-10-09 18:12:09 -06:00
|
|
|
|
|
|
|
denotes the field or method f of the value denoted by x (or of *x if
|
2008-10-23 13:04:45 -06:00
|
|
|
x is of pointer type). The identifier f is called the (field or method)
|
|
|
|
``selector''.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-23 13:04:45 -06:00
|
|
|
A selector f may denote a field f declared in a type T, or it may refer
|
|
|
|
to a field f declared in a nested anonymous field of T. Analogously,
|
|
|
|
f may denote a method f of T, or it may refer to a method f of the type
|
|
|
|
of a nested anonymous field of T. The number of anonymous fields traversed
|
|
|
|
to get to the field or method is called its ``depth'' in T.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-23 13:04:45 -06:00
|
|
|
More precisely, the depth of a field or method f declared in T is zero.
|
|
|
|
The depth of a field or method f declared anywhere inside
|
|
|
|
an anonymous field A declared in T is the depth of f in A plus one.
|
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-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-23 13:04:45 -06:00
|
|
|
1) For a value x of type T or *T where T is not an interface type,
|
|
|
|
x.f denotes the field or method at the shallowest depth in T where there
|
|
|
|
is such an f. The type of x.f is the type of the field or method f.
|
|
|
|
If there is not exactly one f with shallowest depth, the selector
|
|
|
|
expression is illegal.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-23 13:04:45 -06:00
|
|
|
2) For a variable x of type I or *I where I is an interface type,
|
|
|
|
x.f denotes the actual method with name f of the value assigned
|
|
|
|
to x if there is such a method. The type of x.f is the type
|
|
|
|
of the method f. If no value or nil was assigned to x, x.f is illegal.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-23 13:04:45 -06:00
|
|
|
3) In all other cases, x.f is illegal.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-23 13:04:45 -06:00
|
|
|
Thus, selectors automatically dereference pointers as necessary. For instance,
|
|
|
|
for an x of type *T where T declares an f, x.f is a shortcut for (*x).f.
|
|
|
|
Furthermore, for an x of type T containing an anonymous field A declared as *A
|
|
|
|
inside T, and where A contains a field f, x.f is a shortcut for (*x.A).f
|
|
|
|
(assuming that the selector is legal in the first place).
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-23 13:04:45 -06:00
|
|
|
The following examples illustrate selector use in more detail. Given the
|
|
|
|
declarations:
|
|
|
|
|
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
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
one can write:
|
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
|
|
|
|
2008-10-09 18:12:09 -06:00
|
|
|
A primary expression of the form
|
|
|
|
|
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>
|
2008-10-09 18:12:09 -06:00
|
|
|
denotes the array or map element x. The value x is called the
|
|
|
|
``array index'' or ``map key'', respectively. The following
|
|
|
|
rules apply:
|
2009-02-19 18:31:36 -07:00
|
|
|
</p>
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-09 18:12:09 -06:00
|
|
|
For a of type A or *A where A is an array type (§Array types):
|
2009-02-19 18:31:36 -07:00
|
|
|
</p>
|
2009-02-19 17:49:10 -07:00
|
|
|
<ul>
|
|
|
|
<li>x must be an integer value and 0 <= x < len(a)
|
|
|
|
<li>a[x] is the array element at index x and the type of a[x]
|
2008-10-09 18:12:09 -06:00
|
|
|
is the element type of A
|
2009-02-19 17:49:10 -07:00
|
|
|
</ul>
|
|
|
|
<p>
|
2008-10-09 18:12:09 -06:00
|
|
|
For a of type *M, where M is a map type (§Map types):
|
2009-02-19 18:31:36 -07:00
|
|
|
</p>
|
2009-02-19 17:49:10 -07:00
|
|
|
<ul>
|
|
|
|
<li>x must be of the same type as the key type of M
|
2008-10-09 18:12:09 -06:00
|
|
|
and the map must contain an entry with key x
|
2009-02-19 17:49:10 -07:00
|
|
|
<li>a[x] is the map value with key x and the type of a[x]
|
2008-10-09 18:12:09 -06:00
|
|
|
is the value type of M
|
2009-02-19 17:49:10 -07:00
|
|
|
</ul>
|
2008-10-09 18:12:09 -06:00
|
|
|
|
|
|
|
Otherwise a[x] is illegal.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
|
|
|
<font color=red>
|
2008-10-09 18:12:09 -06:00
|
|
|
TODO: Need to expand map rules for assignments of the form v, ok = m[k].
|
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>Slices</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-06 14:23:20 -07:00
|
|
|
Strings, arrays, and slices can be ``sliced'' to construct substrings or descriptors
|
|
|
|
of subarrays. The index expressions in the slice select which elements appear
|
|
|
|
in the result. The result has indexes starting at 0 and length equal to the
|
|
|
|
difference in the index values in the slice. After slicing the array "a"
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
a := [4]int(1, 2, 3, 4);
|
|
|
|
s := a[1:3];
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-06 14:23:20 -07:00
|
|
|
the slice "s" has type "[]int", length 2, and elements
|
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
|
|
|
|
|
|
|
The index values in the slice must be in bounds for the original
|
|
|
|
array (or string) and the slice length must be non-negative.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2009-01-06 14:23:20 -07:00
|
|
|
If the sliced operand is a string, the result of the slice operation is another
|
|
|
|
string (§String types). If the sliced operand is an array or slice, the result
|
|
|
|
of the slice operation is a slice (§Slice types).
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>Type guards</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
For an expression "x" and a type "T", the primary expression
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
x.(T)
|
|
|
|
</pre>
|
2008-11-07 14:34:37 -07:00
|
|
|
|
|
|
|
asserts that the value stored in "x" is an element of type "T" (§Types).
|
|
|
|
The notation ".(T)" is called a ``type guard'', and "x.(T)" is called
|
|
|
|
a ``guarded expression''. The type of "x" must be an interface type.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-11-07 14:34:37 -07:00
|
|
|
More precisely, if "T" is not an interface type, the expression asserts
|
|
|
|
that the dynamic type of "x" is identical to the type "T" (§Types).
|
|
|
|
If "T" is an interface type, the expression asserts that the dynamic type
|
|
|
|
of T implements the interface "T" (§Interface types). Because it can be
|
|
|
|
verified statically, a type guard in which the static type of "x" implements
|
|
|
|
the interface "T" is illegal. The type guard is said to succeed if the
|
|
|
|
assertion holds.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-11-07 14:34:37 -07:00
|
|
|
If the type guard succeeds, the value of the guarded expression is the value
|
|
|
|
stored in "x" and its type is "T". If the type guard fails, a run-time
|
|
|
|
exception occurs. In other words, even though the dynamic type of "x"
|
|
|
|
is only known at run-time, the type of the guarded expression "x.(T)" is
|
|
|
|
known to be "T" in a correct program.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-11-07 14:34:37 -07:00
|
|
|
As a special form, if a guarded expression is used in an assignment
|
|
|
|
|
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
|
|
|
|
|
|
|
the result of the guarded expression is a pair of values with types "(T, bool)".
|
|
|
|
If the type guard succeeds, the expression returns the pair "(x.(T), true)";
|
|
|
|
that is, the value stored in "x" (of type "T") is assigned to "v", and "ok"
|
|
|
|
is set to true. If the type guard fails, the value in "v" is set to the initial
|
|
|
|
value for the type of "v" (§Program initialization and execution), and "ok" is
|
|
|
|
set to false. No run-time exception occurs in this case.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
|
|
|
<font color=red>
|
2008-11-07 14:34:37 -07:00
|
|
|
TODO add examples
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
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
|
|
|
<font color=red>
|
2009-01-30 15:48:29 -07:00
|
|
|
TODO: This needs to be expanded and cleaned up.
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
2009-01-30 15:48:29 -07:00
|
|
|
|
|
|
|
Given a function or a function variable p, one writes
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
p()
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
to call the function.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
A method is called using the notation
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
receiver.method()
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-30 15:48:29 -07:00
|
|
|
where receiver is a value of the receiver type of the method.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
For instance, given a *Point variable pt, one may call
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
pt.Scale(3.5)
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
The type of a method is the type of a function with the receiver as first
|
|
|
|
argument. For instance, the method "Scale" has type
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
(p *Point, factor float)
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
However, a function declared this way is not a method.
|
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-19 17:49:10 -07:00
|
|
|
<h3>Parameter passing</h3>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<font color=red>
|
2008-11-04 17:46:45 -07:00
|
|
|
TODO expand this section (right now only "..." parameters are covered).
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
|
|
|
Inside a function, the type of the "..." parameter is the empty interface
|
|
|
|
"interface {}". The dynamic type of the parameter - that is, the type of
|
2008-11-07 14:34:37 -07:00
|
|
|
the value stored in the parameter - is of the form (in pseudo-
|
2008-11-04 17:46:45 -07:00
|
|
|
notation)
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
*struct {
|
|
|
|
arg(0) typeof(arg(0));
|
|
|
|
arg(1) typeof(arg(1));
|
|
|
|
arg(2) typeof(arg(2));
|
|
|
|
...
|
|
|
|
arg(n-1) typeof(arg(n-1));
|
|
|
|
}
|
|
|
|
</pre>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
|
|
|
where the "arg(i)"'s correspond to the actual arguments passed in place
|
|
|
|
of the "..." parameter (the parameter and type names are for illustration
|
|
|
|
only). Reflection code may be used to access the struct value and its fields.
|
|
|
|
Thus, arguments provided in place of a "..." parameter are wrapped into
|
|
|
|
a corresponding struct, and a pointer to the struct is passed to the
|
|
|
|
function instead of the actual arguments.
|
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
For instance, consider the function
|
2008-11-04 17:46:45 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
func f(x int, s string, f_extra ...)
|
|
|
|
</pre>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
|
|
|
and the call
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
f(42, "foo", 3.14, true, []int(1, 2, 3))
|
|
|
|
</pre>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
2009-02-11 22:57:15 -07:00
|
|
|
Upon invocation, the parameters "3.14", "true", and "[]int(1, 2, 3)"
|
2008-11-04 17:46:45 -07:00
|
|
|
are wrapped into a struct and the pointer to the struct is passed to f.
|
|
|
|
In f the type of parameter "f_extra" is "interface{}".
|
2008-11-07 14:34:37 -07:00
|
|
|
The dynamic type of "f_extra" is the type of the value assigned
|
2008-11-04 17:46:45 -07:00
|
|
|
to it upon invocation (the field names "arg0", "arg1", "arg2" are made
|
|
|
|
up for illustration only, they are not accessible via reflection):
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
*struct {
|
|
|
|
arg0 float;
|
|
|
|
arg1 bool;
|
|
|
|
arg2 []int;
|
|
|
|
}
|
|
|
|
</pre>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
|
|
|
The values of the fields "arg0", "arg1", and "arg2" are "3.14", "true",
|
2009-02-11 22:57:15 -07:00
|
|
|
and "[]int(1, 2, 3)".
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-11-04 17:46:45 -07:00
|
|
|
As a special case, if a function passes a "..." parameter as the argument
|
|
|
|
for a "..." parameter of a function, the parameter is not wrapped again into
|
|
|
|
a struct. Instead it is passed along unchanged. For instance, the function
|
|
|
|
f may call a function g with declaration
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
func g(x int, g_extra ...)
|
|
|
|
</pre>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
|
|
|
as
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
g(x, f_extra);
|
|
|
|
</pre>
|
2008-11-04 17:46:45 -07:00
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
Inside g, the value stored in g_extra is the same as the value stored
|
2008-11-04 17:46:45 -07:00
|
|
|
in f_extra.
|
|
|
|
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>Operators</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-09-04 16:17:27 -06:00
|
|
|
Operators combine operands into expressions.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
Expression = UnaryExpr | Expression binaryOp UnaryExpr .
|
|
|
|
UnaryExpr = PrimaryExpr | unary_op UnaryExpr .
|
2008-10-10 13:45:44 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
binary_op = log_op | com_op | rel_op | add_op | mul_op .
|
|
|
|
log_op = "||" | "&&" .
|
|
|
|
com_op = "<-" .
|
|
|
|
rel_op = "==" | "!=" | "<" | "<=" | ">" | ">=" .
|
|
|
|
add_op = "+" | "-" | "|" | "^" .
|
|
|
|
mul_op = "*" | "/" | "%" | "<<" | ">>" | "&" .
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
unary_op = "+" | "-" | "!" | "^" | "*" | "&" | "<-" .
|
|
|
|
</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
|
|
|
|
the other operand (§Expression).
|
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
|
2008-09-11 19:23:28 -06:00
|
|
|
if one of the operands is an ideal float (relevant for "/" and "%").
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<li>The right operand in a shift operation must be always be an unsigned int
|
2008-10-20 12:46:40 -06:00
|
|
|
(or an ideal number that can be safely converted into an unsigned int)
|
|
|
|
(§Arithmetic operators).
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<li>When comparing two operands of channel type, the channel value types
|
2009-01-26 10:34:19 -07:00
|
|
|
must be equal but the channel direction is ignored.
|
2009-02-19 17:49:10 -07:00
|
|
|
</ul>
|
2009-01-26 10:34:19 -07:00
|
|
|
|
2008-10-10 13:45:44 -06:00
|
|
|
Unary operators have the highest precedence. They are evaluated from
|
2008-10-20 12:46:40 -06:00
|
|
|
right to left. Note that "++" and "--" are outside the unary operator
|
2009-02-20 14:36:14 -07:00
|
|
|
hierarchy (they are statements) and they apply to the operand on the left.
|
2008-10-20 12:46:40 -06:00
|
|
|
Specifically, "*p++" means "(*p)++" in Go (as opposed to "*(p++)" in C).
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-04 16:17:27 -06:00
|
|
|
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-19 17:49:10 -07:00
|
|
|
"&&" (logical and), and finally "||" (logical or) with the
|
2008-09-11 18:48:20 -06:00
|
|
|
lowest precedence:
|
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
|
|
|
|
6 * / % << >> &
|
|
|
|
5 + - | ^
|
|
|
|
4 == != < <= > >=
|
|
|
|
3 <-
|
|
|
|
2 &&
|
|
|
|
1 ||
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-10-10 13:45:44 -06:00
|
|
|
Binary operators of the same precedence associate from left to right.
|
2008-09-04 16:17:27 -06:00
|
|
|
For instance, "x / y / z" stands for "(x / y) / z".
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
Examples
|
|
|
|
|
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
|
|
|
|
type as the first operand. The four standard arithmetic operators ("+", "-",
|
|
|
|
"*", "/") apply to both integer and floating point types, while "+" also applies
|
|
|
|
to strings and arrays; all other arithmetic operators apply to integer types only.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
+ sum integers, floats, strings, arrays
|
|
|
|
- difference integers, floats
|
|
|
|
* product integers, floats
|
|
|
|
/ quotient integers, floats
|
|
|
|
% remainder integers
|
|
|
|
|
|
|
|
& bitwise and integers
|
|
|
|
| bitwise or integers
|
|
|
|
^ bitwise xor integers
|
|
|
|
|
|
|
|
<< left shift integer << unsigned integer
|
|
|
|
>> right shift integer >> unsigned integer
|
|
|
|
</pre>
|
2008-09-04 16:17:27 -06:00
|
|
|
|
2009-02-11 22:57:15 -07:00
|
|
|
Strings can be concatenated using the "+" operator (or the "+=" assignment):
|
2008-09-04 16:17:27 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
s := "hi" + string(c)
|
|
|
|
</pre>
|
2008-09-04 16:17:27 -06:00
|
|
|
|
2009-02-11 22:57:15 -07:00
|
|
|
String addition creates a new string by copying the elements.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-08 16:01:04 -06:00
|
|
|
For integer values, "/" and "%" satisfy the following relationship:
|
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
|
|
|
|
|
|
|
and
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
(a / b) is "truncated towards zero".
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-09-04 16:17:27 -06:00
|
|
|
Examples:
|
|
|
|
|
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
|
|
|
|
2008-09-04 16:17:27 -06:00
|
|
|
Note that if the dividend is positive and the divisor is a constant power of 2,
|
|
|
|
the division may be replaced by a left shift, and computing the remainder may
|
|
|
|
be replaced by a bitwise "and" operation:
|
|
|
|
|
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
|
|
|
|
|
|
|
The shift operators shift the left operand by the shift count specified by the
|
|
|
|
right operand. They implement arithmetic shifts if the left operand is a signed
|
|
|
|
integer, and logical shifts if it is an unsigned integer. The shift count must
|
|
|
|
be an unsigned integer. There is no upper limit on the shift count. It is
|
|
|
|
as if the left operand is shifted "n" times by 1 for a shift count of "n".
|
2008-12-12 11:30:10 -07:00
|
|
|
Specifically, "x << 1" is the same as "x*2"; and "x >> 1" is the same as
|
|
|
|
"x/2 truncated towards negative infinity".
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-12-12 11:30:10 -07:00
|
|
|
For integer operands, the unary operators "+", "-", and "^" are defined as
|
|
|
|
follows:
|
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-02-19 17:49:10 -07:00
|
|
|
<h3>Integer overflow</h3>
|
2008-12-12 11:30:10 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
For unsigned integer values, the operations "+", "-", "*", and "<<" are
|
2008-12-12 11:30:10 -07:00
|
|
|
computed modulo 2^n, where n is the bit width of the unsigned integer type
|
|
|
|
(§Arithmetic types). Loosely speaking, these unsigned integer operations
|
|
|
|
discard high bits upon overflow, and programs may rely on ``wrap around''.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
|
|
|
For signed integers, the operations "+", "-", "*", and "<<" 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.
|
|
|
|
No exception is raised as a result of overflow. As a consequence, a
|
|
|
|
compiler may not optimize code under the assumption that overflow does
|
2009-02-19 17:49:10 -07:00
|
|
|
not occur. For instance, it may not assume that "x < x + 1" is always true.
|
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
|
|
|
|
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-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-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
|
|
|
|
|
|
|
The syntax presented above covers communication operations. This
|
|
|
|
section describes their form and function.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2009-01-05 12:17:26 -07:00
|
|
|
Here the term "channel" means "variable of type chan".
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2009-01-06 14:23:20 -07:00
|
|
|
The built-in function "make" makes a new channel value:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
ch := make(chan int)
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-06 14:23:20 -07:00
|
|
|
An optional argument to "make()" specifies a buffer size for an
|
2008-08-28 18:47:53 -06:00
|
|
|
asynchronous channel; if absent or zero, the channel is synchronous:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
sync_chan := make(chan int)
|
|
|
|
buffered_chan := make(chan int, 10)
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
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-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
ch <- 3
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
In this form, the send operation is an (expression) statement that
|
2008-10-03 12:18:45 -06:00
|
|
|
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.
|
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,
|
|
|
|
false if it did not. These two examples are equivalent:
|
|
|
|
|
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
|
|
|
|
|
|
|
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-19 17:49:10 -07:00
|
|
|
<p>
|
|
|
|
<font color=red>
|
2008-09-17 14:57:11 -06:00
|
|
|
TODO: Adjust the above depending on how we rule on the ok semantics.
|
2008-10-03 12:18:45 -06:00
|
|
|
For instance, does the sent expression get evaluated if ok is false?
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
|
|
|
<p>
|
|
|
|
The receive operation uses the prefix unary operator "<-".
|
2008-09-17 14:57:11 -06:00
|
|
|
The value of the expression is the value received:
|
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
|
|
|
|
|
|
|
The expression blocks until a value is available, which then can
|
|
|
|
be assigned to a variable or used like any other expression:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
v1 := <-ch
|
|
|
|
v2 = <-ch
|
|
|
|
f(<-ch)
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
If the receive expression does not save the value, the value is
|
|
|
|
discarded:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
<-strobe // wait until clock pulse
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-09-17 14:57:11 -06:00
|
|
|
If a receive expression is used in a tuple assignment of the form
|
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
|
|
|
|
2008-09-17 14:57:11 -06:00
|
|
|
the receive operation becomes non-blocking, and the boolean variable
|
|
|
|
"ok" will be set to "true" if the receive operation succeeded, and set
|
|
|
|
to "false" otherwise.
|
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
|
|
|
|
elements. If it contains only numeric literals, its type is ``ideal
|
|
|
|
integer'' or ``ideal float'' (§Ideal number). Whether it is an
|
|
|
|
integer or float depends on whether the value can be represented
|
|
|
|
precisely as an integer (123 vs. 1.23). The nature of the arithmetic
|
|
|
|
operations within the expression depends, elementwise, on the values;
|
|
|
|
for example, 3/2 is an integer division yielding 1, while 3./2. is
|
|
|
|
a floating point division yielding 1.5. Thus
|
|
|
|
</p>
|
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
|
|
|
|
expression can be represented accurately in that context. For
|
|
|
|
instance, 3 can be assigned to any integer variable but also to any
|
|
|
|
floating point variable, while 1e12 can be assigned to a
|
|
|
|
<code>float32</code>, <code>float64</code>, or even <code>int64</code>.
|
|
|
|
It is erroneous to assign a value with a non-zero fractional part
|
|
|
|
to an integer, or if the assignment would overflow or underflow.
|
|
|
|
</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
|
|
|
|
|
|
|
Statements control execution.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
Statement =
|
|
|
|
Declaration | LabelDecl | EmptyStat |
|
|
|
|
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 .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-10-09 21:05:24 -06:00
|
|
|
|
2008-10-08 18:05:30 -06:00
|
|
|
Statements in a statement list are separated by semicolons, which can be
|
|
|
|
omitted in some cases as expressed by the OptSemicolon production.
|
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
|
|
|
StatementList = Statement { OptSemicolon Statement } .
|
|
|
|
</pre>
|
2008-10-09 21:05:24 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2009-02-19 18:31:36 -07:00
|
|
|
A semicolon may be omitted immediately following:
|
|
|
|
</p>
|
2009-02-19 17:49:10 -07:00
|
|
|
<ul>
|
2009-02-23 20:22:05 -07:00
|
|
|
<li>a closing parenthesis ")" ending a list of declarations (§Declarations and Scope)
|
2009-02-19 17:49:10 -07:00
|
|
|
<li>a closing brace "}" ending a type declaration (§Type declarations)
|
|
|
|
<li>a closing brace "}" ending a block (including switch and select statements)
|
|
|
|
<li>a label declaration (§Label declarations)
|
|
|
|
</ul>
|
2008-10-09 21:05:24 -06:00
|
|
|
|
|
|
|
In all other cases a semicolon is required to separate two statements. Since there
|
|
|
|
is an empty statement, a statement list can always be ``terminated'' with a semicolon.
|
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
|
|
|
|
|
|
|
The empty statement does nothing.
|
|
|
|
|
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-19 17:49:10 -07:00
|
|
|
<h3>Expression statements</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
|
|
|
ExpressionStat = Expression .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
f(x+y)
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<font color=red>
|
2008-10-08 18:05:30 -06:00
|
|
|
TODO: specify restrictions. 6g only appears to allow calls here.
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
2008-10-08 18:05:30 -06:00
|
|
|
|
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
|
|
|
|
2008-09-30 14:02:50 -06:00
|
|
|
The "++" and "--" statements increment or decrement their operands
|
|
|
|
by the (ideal) constant value 1.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
IncDecStat = Expression ( "++" | "--" ) .
|
|
|
|
</pre>
|
2008-09-30 14:02:50 -06:00
|
|
|
|
|
|
|
The following assignment statements (§Assignments) are semantically
|
|
|
|
equivalent:
|
|
|
|
|
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
|
|
|
|
2008-09-30 14:02:50 -06:00
|
|
|
Both operators apply to integer and floating point types only.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-30 14:02:50 -06:00
|
|
|
Note that increment and decrement are statements, not expressions.
|
|
|
|
For instance, "x++" cannot be used as an operand in an expression.
|
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
|
|
|
|
|
|
|
The left-hand side must be an l-value such as a variable, pointer indirection,
|
|
|
|
or an array index.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
x = 1
|
|
|
|
*p = f()
|
|
|
|
a[i] = 23
|
|
|
|
k = <-ch
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
As in C, arithmetic binary operators can be combined with assignments:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
j <<= 2
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
A tuple assignment assigns the individual elements of a multi-valued operation,
|
|
|
|
such as function evaluation or some channel and map operations, into individual
|
|
|
|
variables. For instance, a tuple assignment such as
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
v1, v2, v3 = e1, e2, e3
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
assigns the expressions e1, e2, e3 to temporaries and then assigns the temporaries
|
|
|
|
to the variables v1, v2, v3. Thus
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
a, b = b, a
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
exchanges the values of a and b. The tuple assignment
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
x, y = f()
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
calls the function f, which must return two values, and assigns them to x and y.
|
|
|
|
As a special case, retrieving a value from a map, when written as a two-element
|
|
|
|
tuple assignment, assign a value and a boolean. If the value is present in the map,
|
|
|
|
the value is assigned and the second, boolean variable is set to true. Otherwise,
|
|
|
|
the variable is unchanged, and the boolean value is set to false.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
value, present = map_var[key]
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
To delete a value from a map, use a tuple assignment with the map on the left
|
|
|
|
and a false boolean expression as the second expression on the right, such
|
|
|
|
as:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
map_var[key] = value, false
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
In assignments, the type of the expression must match the type of the left-hand side.
|
|
|
|
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>If statements</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-09-26 12:15:14 -06:00
|
|
|
If statements specify the conditional execution of two branches; the "if"
|
|
|
|
and the "else" branch. If Expression evaluates to true,
|
|
|
|
the "if" branch is executed. Otherwise the "else" branch is executed if present.
|
|
|
|
If Condition is omitted, it is equivalent to true.
|
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
|
|
|
IfStat = "if" [ [ SimpleStat ] ";" ] [ Expression ] Block [ "else" Statement ] .
|
|
|
|
</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
|
|
|
|
|
|
|
An "if" statement may include the declaration of a single temporary variable.
|
|
|
|
The scope of the declared variable extends to the end of the if statement, and
|
|
|
|
the variable is initialized once before the statement is entered.
|
|
|
|
|
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
|
|
|
|
|
|
|
|
2008-09-26 12:15:14 -06:00
|
|
|
<!--
|
|
|
|
TODO: gri thinks that Statement needs to be changed as follows:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
IfStat =
|
2009-01-30 15:48:29 -07:00
|
|
|
"if" [ [ SimpleStat ] ";" ] [ Expression ] Block
|
2008-09-26 12:15:14 -06:00
|
|
|
[ "else" ( IfStat | Block ) ] .
|
|
|
|
|
|
|
|
To facilitate the "if else if" code pattern, if the "else" branch is
|
|
|
|
simply another "if" statement, that "if" statement may be written
|
|
|
|
without the surrounding Block:
|
|
|
|
|
|
|
|
if x > 0 {
|
|
|
|
return 0;
|
|
|
|
} else if x > 10 {
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
return 2;
|
|
|
|
}
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-09-26 12:15:14 -06:00
|
|
|
-->
|
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
|
|
|
|
|
|
|
Switches provide multi-way execution.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
SwitchStat = "switch" [ [ SimpleStat ] ";" ] [ Expression ] "{" { CaseClause } "}" .
|
|
|
|
CaseClause = SwitchCase ":" [ StatementList ] .
|
|
|
|
SwitchCase = "case" ExpressionList | "default" .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-10-08 18:05:30 -06:00
|
|
|
There can be at most one default case in a switch statement. In a case clause,
|
|
|
|
the last statement only may be a fallthrough statement ($Fallthrough statement).
|
|
|
|
It indicates that the control should flow from the end of this case clause to
|
|
|
|
the first statement of the next clause.
|
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
|
|
|
|
($Declarations and scope rules).
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
The expressions do not need to be constants. They will
|
|
|
|
be evaluated top to bottom until the first successful non-default case is reached.
|
|
|
|
If none matches and there is a default case, the statements of the default
|
|
|
|
case are executed.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
switch tag {
|
|
|
|
default: s3()
|
|
|
|
case 0, 1: s1()
|
|
|
|
case 2: s2()
|
|
|
|
}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
A switch statement may include the declaration of a single temporary variable.
|
|
|
|
The scope of the declared variable extends to the end of the switch statement, and
|
|
|
|
the variable is initialized once before the switch is entered.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
switch x := f(); true {
|
|
|
|
case x < 0: return -x
|
|
|
|
default: return x
|
|
|
|
}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
Cases do not fall through unless explicitly marked with a "fallthrough" statement.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
switch a {
|
|
|
|
case 1:
|
|
|
|
b();
|
|
|
|
fallthrough
|
|
|
|
case 2:
|
|
|
|
c();
|
|
|
|
}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
If the expression is omitted, it is equivalent to "true".
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
switch {
|
|
|
|
case x < y: f1();
|
|
|
|
case x < z: f2();
|
|
|
|
case x == 4: f3();
|
|
|
|
}
|
|
|
|
</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
|
|
|
|
2008-12-16 12:38:56 -07:00
|
|
|
A for statement specifies repeated execution of a block. The iteration is
|
|
|
|
controlled by a condition, a for clause, or a range clause.
|
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
|
|
|
|
2008-12-16 12:38:56 -07:00
|
|
|
In its simplest form, a for statement specifies the repeated execution of
|
|
|
|
a block as long as a condition evaluates to true. The condition is evaluated
|
|
|
|
before each iteration. The type of the condition expression must be boolean.
|
|
|
|
If the condition is absent, it is equivalent to "true".
|
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
|
|
|
|
2008-12-16 12:38:56 -07:00
|
|
|
A for statement with a for clause is also controlled by its condition, but
|
|
|
|
additionally it may specify an init and post statement, such as an assignment,
|
|
|
|
an increment or decrement statement. The init statement may also be a (simple)
|
|
|
|
variable declaration; no variables can be declared in the post statement.
|
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
|
|
|
|
2008-12-16 12:38:56 -07:00
|
|
|
For instance, one may declare an iteration variable in the init statement:
|
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>
|
2008-12-16 12:38:56 -07:00
|
|
|
|
|
|
|
If present, the init statement is executed once before commencing the iteration;
|
|
|
|
the post statement is executed after each execution of the statement block (and
|
|
|
|
only if the block was executed). The scope of any variable declared in the init
|
|
|
|
statement ends with the end of the for statement block ($Declarations and scope
|
|
|
|
rules, Rule 3).
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-12-16 12:38:56 -07:00
|
|
|
The init and post statement as well as the condition may be omitted; however
|
|
|
|
if either the init or post statement are present, the separating semicolons
|
|
|
|
must be present. If the condition is absent, it is equivalent to "true".
|
|
|
|
The following statements are equivalent:
|
|
|
|
|
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
|
|
|
|
|
|
|
Alternatively, a for statement may be controlled by a range clause. A
|
|
|
|
range clause specifies iteration through all entries of an array or map.
|
|
|
|
For each entry it first assigns the current index or key to an iteration
|
|
|
|
variable - or the current (index, element) or (key, value) pair to a pair
|
|
|
|
of iteration variables - and then executes the block. Iteration terminates
|
|
|
|
when all entries have been processed, or if the for statement is terminated
|
|
|
|
early, for instance by a break or return statement.
|
|
|
|
|
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
|
|
|
|
|
|
|
The type of the right-hand expression in the range clause must be an array or
|
|
|
|
map, or a pointer to an array or map. If it is a pointer, it must not be nil.
|
|
|
|
The left-hand identifier list must contain one or two identifiers denoting the
|
|
|
|
iteration variables. The first variable is set to the current array index or
|
|
|
|
map key, and the second variable, if present, is set to the corresponding
|
|
|
|
array element or map value. The types of the array index (int) and element,
|
|
|
|
or of the map key and value respectively, must be assignment-compatible to
|
|
|
|
the iteration variables.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-12-16 12:38:56 -07:00
|
|
|
The iteration variables may be declared by the range clause (":="), in which
|
|
|
|
case their scope ends at the end of the for statement block ($Declarations and
|
|
|
|
scope rules, Rule 3). In this case their types are the array index and element,
|
|
|
|
or the map key and value types, respectively.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
var a [10]string;
|
|
|
|
m := map[string]int("mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6);
|
|
|
|
|
|
|
|
for i, s := range a {
|
|
|
|
// type of i is int
|
|
|
|
// type of s is string
|
|
|
|
// s == a[i]
|
|
|
|
g(i, s)
|
|
|
|
}
|
|
|
|
|
|
|
|
var key string;
|
|
|
|
var val interface {}; // value type of m is assignment-compatible to val
|
|
|
|
for key, value = range m {
|
|
|
|
h(key, value)
|
|
|
|
}
|
|
|
|
// key == last map key encountered in iteration
|
|
|
|
// val == map[key]
|
|
|
|
</pre>
|
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
|
|
|
|
behavior is implementation-dependent. Likewise, if the range expression is a
|
|
|
|
pointer variable, the behavior of assigning to that variable is implementation-
|
|
|
|
dependent. Assigning to the iteration variables during iteration simply changes
|
|
|
|
the values of those variables for the current iteration; it does not affect any
|
|
|
|
subsequent iterations.
|
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
|
|
|
|
|
|
|
A go statement starts the execution of a function as an independent
|
2008-10-10 13:45:44 -06:00
|
|
|
concurrent thread of control within the same address space. The expression
|
2009-01-27 15:51:24 -07:00
|
|
|
must be a function or method call.
|
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
|
|
|
|
2008-09-26 14:38:38 -06:00
|
|
|
Unlike with a regular function call, program execution does not wait
|
|
|
|
for the invoked function to complete.
|
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
|
|
|
|
|
|
|
A select statement chooses which of a set of possible communications
|
|
|
|
will proceed. It looks similar to a switch statement but with the
|
|
|
|
cases all referring to communication operations.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
SelectStat = "select" "{" { CommClause } "}" .
|
|
|
|
CommClause = CommCase ":" [ StatementList ] .
|
|
|
|
CommCase = "case" ( SendExpr | RecvExpr) | "default" .
|
|
|
|
SendExpr = Expression "<-" Expression .
|
|
|
|
RecvExpr = [ Expression ( "=" | ":=" ) ] "<-" Expression .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
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-19 17:49:10 -07:00
|
|
|
<p>
|
2008-10-03 12:18:45 -06:00
|
|
|
For all the send and receive expressions in the select
|
|
|
|
statement, the channel expression is evaluated. Any values
|
|
|
|
that appear on the right hand side of send expressions are also
|
|
|
|
evaluated. If any of the resulting channels can proceed, one is
|
|
|
|
chosen and the corresponding communication and statements are
|
|
|
|
evaluated. Otherwise, if there is a default case, that executes;
|
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.
|
|
|
|
A channel pointer may be nil, which is equivalent to that case not
|
|
|
|
being present in the select statement.
|
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
|
|
|
|
in the select.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-17 14:57:11 -06:00
|
|
|
If the channel sends or receives an interface type, its
|
2008-08-28 18:47:53 -06:00
|
|
|
communication can proceed only if the type of the communication
|
|
|
|
clause matches that of the dynamic value to be exchanged.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
If multiple cases can proceed, a uniform fair choice is made regarding
|
|
|
|
which single communication will execute.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-17 14:57:11 -06:00
|
|
|
The receive case may declare a new variable (via a ":=" assignment). The
|
|
|
|
scope of such variables begins immediately after the variable identifier
|
|
|
|
and ends at the end of the respective "select" case (that is, before the
|
|
|
|
next "case", "default", or closing brace).
|
|
|
|
|
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
|
|
|
|
|
|
|
A return statement terminates execution of the containing function
|
|
|
|
and optionally provides a result value or values to the caller.
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
There are two ways to return values from a function. The first is to
|
|
|
|
explicitly list the return value or values in the return statement:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
func simple_f() int {
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
A function may return multiple values.
|
|
|
|
The syntax of the return clause in that case is the same as
|
|
|
|
that of a parameter list; in particular, names must be provided for
|
|
|
|
the elements of the return value.
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
func complex_f1() (re float, im float) {
|
|
|
|
return -7.0, -4.0;
|
|
|
|
}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-10-07 18:14:30 -06:00
|
|
|
A second method to return values
|
2008-08-28 18:47:53 -06:00
|
|
|
is to use those names within the function as variables
|
|
|
|
to be assigned explicitly; the return statement will then provide no
|
|
|
|
values:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
func complex_f2() (re float, im float) {
|
|
|
|
re = 7.0;
|
|
|
|
im = 4.0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>Break statements</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
Within a for, switch, or select statement, a break statement terminates
|
|
|
|
execution of the innermost such statement.
|
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
|
|
|
BreakStat = "break" [ identifier ].
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
If there is an identifier, it must be a label marking an enclosing
|
|
|
|
for, switch, or select statement, and that is the one whose execution
|
|
|
|
terminates.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
L: for i < n {
|
|
|
|
switch i {
|
|
|
|
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
|
|
|
|
|
|
|
Within a for loop a continue statement begins the next iteration of the
|
|
|
|
loop at the post statement.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
ContinueStat = "continue" [ identifier ].
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
The optional identifier is analogous to that of a break statement.
|
|
|
|
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>Label declarations</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
A label declaration serves as the target of a goto, break or continue statement.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
LabelDecl = identifier ":" .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-11-07 14:34:37 -07:00
|
|
|
Example:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
Error:
|
|
|
|
</pre>
|
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
|
|
|
|
|
|
|
A goto statement transfers control to the corresponding label statement.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
GotoStat = "goto" identifier .
|
|
|
|
</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
|
|
|
|
|
|
|
Executing the goto statement must not cause any variables to come into
|
|
|
|
scope that were not already in scope at the point of the goto. For
|
|
|
|
instance, this example:
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
goto L; // BAD
|
|
|
|
v := 3;
|
|
|
|
L:
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
is erroneous because the jump to label L skips the creation of v.
|
|
|
|
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>Fallthrough statements</h3>
|
2008-10-08 18:05:30 -06:00
|
|
|
|
|
|
|
A fallthrough statement transfers control to the first statement of the
|
|
|
|
next case clause in a switch statement (§Switch statements). It may only
|
|
|
|
be used in a switch statement, and only as the last statement in a case
|
|
|
|
clause of the switch statement.
|
|
|
|
|
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
|
|
|
|
|
|
|
A defer statement invokes a function whose execution is deferred to the moment
|
|
|
|
when the surrounding function returns.
|
|
|
|
|
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-01-27 15:51:24 -07:00
|
|
|
The expression must be a function or method call. Each time the defer statement
|
|
|
|
executes, the parameters to the function call are evaluated and saved anew but the
|
2009-01-27 10:29:40 -07:00
|
|
|
function is not invoked. Immediately before the innermost function surrounding
|
|
|
|
the defer statement returns, but after its return value (if any) is evaluated,
|
|
|
|
each deferred function is executed with its saved parameters. Deferred functions
|
|
|
|
are executed in LIFO order.
|
|
|
|
|
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-19 17:49:10 -07:00
|
|
|
Call Argument type Result
|
|
|
|
|
|
|
|
len(s) string, *string string length (in bytes)
|
|
|
|
[n]T, *[n]T array length (== n)
|
|
|
|
[]T, *[]T slice length
|
|
|
|
map[K]T, *map[K]T map length
|
|
|
|
chan T number of elements in channel buffer
|
|
|
|
|
|
|
|
cap(s) []T, *[]T capacity of s
|
|
|
|
map[K]T, *map[K]T capacity of s
|
|
|
|
chan T channel buffer capacity
|
|
|
|
</pre>
|
2009-01-06 14:23:20 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<font color=red>
|
2009-01-06 14:23:20 -07:00
|
|
|
TODO: confirm len() and cap() for channels
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
2009-01-06 14:23:20 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2009-01-06 14:23:20 -07:00
|
|
|
The type of the result is always "int" and the implementation guarantees that
|
|
|
|
the result always fits into an "int".
|
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
|
|
|
|
space allocated in the underlying array (for a slice) or map. For a slice "s",
|
|
|
|
at any time the following relationship holds:
|
|
|
|
|
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
|
|
|
|
2008-09-26 15:04:21 -06:00
|
|
|
Conversions syntactically look like function calls of the form
|
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
|
|
|
|
2008-09-26 15:04:21 -06:00
|
|
|
where "T" is the type name of an arithmetic type or string (§Basic types),
|
|
|
|
and "value" is the value of an expression which can be converted to a value
|
|
|
|
of result type "T".
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-26 15:04:21 -06:00
|
|
|
The following conversion rules apply:
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
1) Between integer types. If the value is a signed quantity, it is
|
|
|
|
sign extended to implicit infinite precision; otherwise it is zero
|
|
|
|
extended. It is then truncated to fit in the result type size.
|
|
|
|
For example, uint32(int8(0xFF)) is 0xFFFFFFFF. The conversion always
|
|
|
|
yields a valid value; there is no signal for overflow.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
2) Between integer and floating point types, or between floating point
|
|
|
|
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>
|
|
|
|
<p>
|
2008-09-26 15:04:21 -06:00
|
|
|
3) Strings permit two special conversions.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-26 15:04:21 -06:00
|
|
|
3a) 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-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
string(0x65e5) // "\u65e5"
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-24 16:17:59 -07:00
|
|
|
3b) Converting an array of <code>uint8s</code> yields a string whose successive
|
|
|
|
bytes are those of the array.
|
|
|
|
(Recall <code>byte</code> is a synonym for <code>uint8</code>.)
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
string([]byte('h', 'e', 'l', 'l', 'o')) // "hello"
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-09-26 15:04:21 -06:00
|
|
|
There is no linguistic mechanism to convert between pointers
|
2008-08-28 18:47:53 -06:00
|
|
|
and integers. A library may be provided under restricted circumstances
|
2008-09-26 15:04:21 -06:00
|
|
|
to acccess this conversion in low-level code.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
|
|
|
<font color=red>
|
2008-09-26 15:04:21 -06:00
|
|
|
TODO: Do we allow interface/ptr conversions in this form or do they
|
|
|
|
have to be written as type guards? (§Type guards)
|
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>Allocation</h3>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-06 14:23:20 -07:00
|
|
|
The built-in function "new" takes a type "T" and returns a value of type "*T".
|
2009-01-05 12:17:26 -07:00
|
|
|
The memory is initialized as described in the section on initial values
|
2008-11-07 14:34:37 -07:00
|
|
|
(§Program initialization and execution).
|
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
|
|
|
|
2008-09-09 11:37:19 -06:00
|
|
|
For instance
|
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
|
|
|
|
2008-09-09 11:37:19 -06:00
|
|
|
dynamically allocates memory for a variable of type S, initializes it
|
|
|
|
(a=0, b=0.0), and returns a value of type *S pointing to that variable.
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
|
|
|
<font color=red>
|
2009-01-06 14:23:20 -07:00
|
|
|
TODO Once this has become clearer, connect new() and make() (new() may be
|
|
|
|
explained by make() and vice versa).
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
2009-01-06 14:23:20 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<h3>Making slices, maps, and channels</h3>
|
2009-01-06 14:23:20 -07:00
|
|
|
|
|
|
|
The built-in function "make" takes a type "T", optionally followed by a
|
|
|
|
type-specific list of expressions. It returns a value of type "T". "T"
|
|
|
|
must be a slice, map, or channel type.
|
|
|
|
The memory is initialized as described in the section on initial values
|
|
|
|
(§Program initialization and execution).
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
make(T [, optional list of expressions])
|
|
|
|
</pre>
|
2009-01-06 14:23:20 -07:00
|
|
|
|
|
|
|
For instance
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
make(map[string] int)
|
|
|
|
</pre>
|
2009-01-06 14:23:20 -07:00
|
|
|
|
|
|
|
creates a new map value and initializes it to an empty map.
|
|
|
|
|
|
|
|
The only defined parameters affect sizes for allocating slices, maps, and
|
|
|
|
buffered channels:
|
|
|
|
|
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-19 17:49:10 -07:00
|
|
|
<font color=red>
|
2009-01-06 14:23:20 -07:00
|
|
|
TODO Once this has become clearer, connect new() and make() (new() may be
|
|
|
|
explained by make() and vice versa).
|
2009-02-19 17:49:10 -07:00
|
|
|
</font>
|
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
|
|
|
|
|
|
|
A package is a package clause, optionally followed by import declarations,
|
|
|
|
followed by a series of declarations.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
Package = PackageClause { ImportDecl [ ";" ] } { Declaration [ ";" ] } .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2008-10-03 15:04:28 -06:00
|
|
|
The source text following the package clause acts like a block for scoping
|
|
|
|
purposes ($Declarations and scope rules).
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
Every source file identifies the package to which it belongs.
|
|
|
|
The file must begin with a package clause.
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
PackageClause = "package" PackageName .
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
package Math
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
|
2009-01-16 15:12:50 -07:00
|
|
|
A package can gain access to exported identifiers from another package
|
2008-08-28 18:47:53 -06:00
|
|
|
through an import declaration:
|
|
|
|
|
2009-02-20 14:36:14 -07:00
|
|
|
<pre class="grammar">
|
2009-02-19 17:49:10 -07:00
|
|
|
ImportDecl = "import" ( ImportSpec | "(" [ ImportSpecList ] ")" ) .
|
|
|
|
ImportSpecList = ImportSpec { ";" ImportSpec } [ ";" ] .
|
|
|
|
ImportSpec = [ "." | PackageName ] PackageFileName .
|
|
|
|
PackageFileName = StringLit .
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-23 20:22:05 -07:00
|
|
|
An import statement makes the exported package-level identifiers of the named
|
2009-01-16 15:12:50 -07:00
|
|
|
package file accessible to this package.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
In the following discussion, assume we have a package in the
|
2009-01-16 15:12:50 -07:00
|
|
|
file "/lib/math", called package "math", which exports the identifiers
|
|
|
|
"Sin" and "Cos" denoting the respective trigonometric functions.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
In the general form, with an explicit package name, the import
|
|
|
|
statement declares that package name as an identifier whose
|
|
|
|
contents are the exported elements of the imported package.
|
|
|
|
For instance, after
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
import M "/lib/math"
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
the contents of the package /lib/math can be accessed by
|
2009-01-16 15:12:50 -07:00
|
|
|
"M.Sin", "M.Cos", etc.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
In its simplest form, with no package name, the import statement
|
|
|
|
implicitly uses the imported package name itself as the local
|
|
|
|
package name. After
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
import "/lib/math"
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-16 15:12:50 -07:00
|
|
|
the contents are accessible by "math.Sin", "math.Cos".
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
Finally, if instead of a package name the import statement uses
|
|
|
|
an explicit period, the contents of the imported package are added
|
|
|
|
to the current package. After
|
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
import . "/lib/math"
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-01-16 15:12:50 -07:00
|
|
|
the contents are accessible by "Sin" and "Cos". In this instance, it is
|
2008-08-28 18:47:53 -06:00
|
|
|
an error if the import introduces name conflicts.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-03 16:15:51 -06:00
|
|
|
Here is a complete example Go package that implements a concurrent prime sieve:
|
2008-08-28 18:47:53 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
package main
|
|
|
|
|
|
|
|
// Send the sequence 2, 3, 4, ... to channel 'ch'.
|
|
|
|
func generate(ch chan <- int) {
|
|
|
|
for i := 2; ; i++ {
|
|
|
|
ch <- i // Send 'i' to channel 'ch'.
|
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'.
|
|
|
|
func filter(in chan <- int, out *<-chan int, prime int) {
|
|
|
|
for {
|
|
|
|
i := <-in; // Receive value of new variable 'i' from 'in'.
|
|
|
|
if i % prime != 0 {
|
|
|
|
out <- i // Send 'i' to channel 'out'.
|
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;
|
|
|
|
print(prime, "\n");
|
|
|
|
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
|
|
|
|
|
|
|
When memory is allocated to store a value, either through a declaration
|
2008-09-30 14:02:50 -06:00
|
|
|
or "new()", 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
|
|
|
|
set to the ``zero'' for that type: "false" for booleans, "0" for integers,
|
2008-09-30 14:02:50 -06:00
|
|
|
"0.0" for floats, '''' for strings, and "nil" for pointers and interfaces.
|
2009-02-20 14:36:14 -07:00
|
|
|
This initialization is done recursively, so for instance each element of an
|
2008-09-30 14:02:50 -06:00
|
|
|
array of integers will be set to 0 if no other value is specified.
|
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-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
var i int;
|
|
|
|
var i int = 0;
|
|
|
|
</pre>
|
2008-08-28 18:47:53 -06:00
|
|
|
|
|
|
|
After
|
|
|
|
|
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
|
|
|
|
|
|
|
the following holds:
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
A package with no imports is initialized by assigning initial values to
|
|
|
|
all its global variables in declaration order and then calling any init()
|
|
|
|
functions defined in its source. Since a package may contain more
|
|
|
|
than one source file, there may be more than one init() function, but
|
|
|
|
only one per source file.
|
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
|
|
|
|
thread of execution.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-09-26 17:41:50 -06:00
|
|
|
Furthermore, an "init()" function cannot be referred to from anywhere
|
|
|
|
in a program. In particular, "init()" cannot be called explicitly, nor
|
|
|
|
can a pointer to "init" be assigned to a function variable).
|
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
|
2008-08-28 18:47:53 -06:00
|
|
|
a package P, P will be initialized only once.
|
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-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
A complete program, possibly created by linking multiple packages,
|
|
|
|
must have one package called main, with a function
|
2008-09-09 11:37:19 -06:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
<pre>
|
|
|
|
func main() { ... }
|
|
|
|
</pre>
|
2008-09-09 11:37:19 -06:00
|
|
|
|
2008-08-28 18:47:53 -06:00
|
|
|
defined. The function main.main() takes no arguments and returns no
|
|
|
|
value.
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
Program execution begins by initializing the main package and then
|
|
|
|
invoking main.main().
|
2009-02-19 17:49:10 -07:00
|
|
|
<p>
|
2008-08-28 18:47:53 -06:00
|
|
|
When main.main() returns, the program exits.
|
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-23 20:22:05 -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:
|
|
|
|
</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
|
|
|
|
variable of any type and returns the size of the variable in bytes.
|
|
|
|
</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
|
|
|
|
a variable <code>x</code> of the largest arithmetic type (8 for a
|
|
|
|
<code>float64</code>), but may
|
|
|
|
be smaller on systems with weaker alignment restrictions.
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
Calls to <code>Alignof</code>, <code>Offsetof</code>, and
|
|
|
|
<code>Sizeof</code> are constant expressions of type <code>int</code>.
|
|
|
|
</p>
|
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-02-23 20:22:05 -07:00
|
|
|
For the arithmetic types (§Arithmetic 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-02-23 20:22:05 -07:00
|
|
|
<li>For a variable <code>x</code> of arithmetic type: <code>unsafe.Alignof(x)</code> is the smaller
|
|
|
|
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>
|
|
|
|
Current implementation accepts only ASCII digits for digits; doc says Unicode.
|
|
|
|
<br>
|
|
|
|
</font>
|
|
|
|
</p>
|
2009-02-11 14:46:30 -07:00
|
|
|
|
2009-02-19 17:49:10 -07:00
|
|
|
</div>
|
|
|
|
</body>
|
|
|
|
</html>
|