1
0
mirror of https://github.com/golang/go synced 2024-11-24 17:30:18 -07:00

- syntax for composite literals use () instead of {}

- do not permit + for array concatenation anymore
  (not implemented and not a good idea)
- document that unsafe function results are compile time constants
- fixed minor typos

DELTA=41  (7 added, 11 deleted, 23 changed)
OCL=24899
CL=24927
This commit is contained in:
Robert Griesemer 2009-02-11 21:57:15 -08:00
parent 5f4f5647ef
commit 6f8df7aa3e

View File

@ -1,7 +1,7 @@
The Go Programming Language Specification (DRAFT)
----
Robert Griesemer, Rob Pike, Ken Thompson
Russ Cox, Robert Griesemer, Rob Pike, Ian Taylor, Ken Thompson
(February 11, 2009)
@ -19,6 +19,7 @@ Any part may change substantially as design progresses.
<!--
Biggest open issues:
[ ] General iterators
[ ] Conversions:
- current situation is messy
- 2 (3?) different notations for the same thing
@ -39,7 +40,7 @@ Decisions in need of integration into the doc:
Todo's:
[ ] there is some funny-ness regarding ';' and empty statements and label decls
[ ] document illegality of package-external tuple assignments to structs
w/ private fields: P.T{1, 2} illegal since same as P.T{a: 1, b: 2} for
w/ private fields: P.T(1, 2) illegal since same as P.T(a: 1, b: 2) for
a T struct { a b int }.
[ ] clarification on interface types, rules
[ ] clarify tuples
@ -67,12 +68,12 @@ Smaller issues:
[ ] Do we allow empty statements? If so, do we allow empty statements after a label?
and if so, does a label followed by an empty statement (a semicolon) still denote
a for loop that is following, and can break L be used inside it?
[ ] 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
Closed:
[x] Russ: If we use x.(T) for all conversions, we could use T() for "construction"
and type literals - would resolve the parsing ambiguity of T{} in if's -
switching to () for literals, conversion discussion still open
[x] Russ: consider re-introducing "func" for function type. Make function literals
behave like slices, etc. Require no &'s to get a function value (solves issue
of func{} vs &func{} vs &func_name).
@ -1820,7 +1821,7 @@ Literals for composite data structures consist of the type of the value
followed by a braced expression list for array, slice, and structure literals,
or a list of expression pairs for map literals.
CompositeLit = LiteralType "{" [ ( ExpressionList | ExprPairList ) [ "," ] ] "}" .
CompositeLit = LiteralType "(" [ ( ExpressionList | ExprPairList ) [ "," ] ] ")" .
LiteralType = Type | "[" "..." "]" ElementType .
ExprPairList = ExprPair { "," ExprPair } .
ExprPair = Expression ":" Expression .
@ -1839,7 +1840,7 @@ Given
one can write
pi := Num{Rat{22, 7}, 3.14159, "pi"};
pi := Num(Rat(22, 7), 3.14159, "pi");
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
@ -1848,24 +1849,24 @@ 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.
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
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
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
[]T{x1, x2, ... xn}
[]T(x1, x2, ... xn)
is essentially a shortcut for a slice operation applied to an array literal:
[n]T{x1, x2, ... xn}[0 : n]
[n]T(x1, x2, ... xn)[0 : n]
Map literals are similar except the elements of the expression list are
key-value pairs separated by a colon:
m := map[string]int{"good": 0, "bad": 1, "indifferent": 7};
m := map[string]int("good": 0, "bad": 1, "indifferent": 7);
TODO: Consider adding helper syntax for nested composites
(avoids repeating types but complicates the spec needlessly.)
@ -2045,7 +2046,7 @@ 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"
a := [4]int{1, 2, 3, 4};
a := [4]int(1, 2, 3, 4);
s := a[1:3];
the slice "s" has type "[]int", length 2, and elements
@ -2163,9 +2164,9 @@ For instance, consider the function
and the call
f(42, "foo", 3.14, true, &[]int{1, 2, 3})
f(42, "foo", 3.14, true, []int(1, 2, 3))
Upon invocation, the parameters "3.14", "true", and "*[3]int{1, 2, 3}"
Upon invocation, the parameters "3.14", "true", and "[]int(1, 2, 3)"
are wrapped into a struct and the pointer to the struct is passed to f.
In f the type of parameter "f_extra" is "interface{}".
The dynamic type of "f_extra" is the type of the value assigned
@ -2175,11 +2176,11 @@ up for illustration only, they are not accessible via reflection):
*struct {
arg0 float;
arg1 bool;
arg2 *[3]int;
arg2 []int;
}
The values of the fields "arg0", "arg1", and "arg2" are "3.14", "true",
and "*[3]int{1, 2, 3}".
and "[]int(1, 2, 3)".
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
@ -2282,14 +2283,11 @@ to strings and arrays; all other arithmetic operators apply to integer types onl
<< left shift integer << unsigned integer
>> right shift integer >> unsigned integer
Strings and arrays can be concatenated using the "+" operator
(or via the "+=" assignment):
Strings can be concatenated using the "+" operator (or the "+=" assignment):
s := "hi" + string(c)
a += []int{5, 6, 7}
String and array addition creates a new array or string by copying the
elements.
String addition creates a new string by copying the elements.
For integer values, "/" and "%" satisfy the following relationship:
@ -2846,7 +2844,7 @@ scope rules, Rule 3). In this case their types are the array index and element,
or the map key and value types, respectively.
var a [10]string;
m := map[string]int{"mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6};
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
@ -3177,11 +3175,6 @@ Predeclared functions
typeof
TODO: (gri) suggests that we should consider assert() as a built-in function.
It is like panic, but takes a boolean guard as first argument. (rsc also thinks
this is a good idea).
Length and capacity
----
@ -3244,7 +3237,7 @@ representation of the integer.
3b) Converting an array of uint8s yields a string whose successive
bytes are those of the array. (Recall byte is a synonym for uint8.)
string([]byte{'h', 'e', 'l', 'l', 'o'}) // "hello"
string([]byte('h', 'e', 'l', 'l', 'o')) // "hello"
There is no linguistic mechanism to convert between pointers
and integers. A library may be provided under restricted circumstances
@ -3481,7 +3474,7 @@ Systems considerations
Package unsafe
----
The special package "unsafe", known to the compiler, provides facilities
The built-in package "unsafe", known to the compiler, provides facilities
for low-level programming including operations that violate the Go type
system. A package using "unsafe" must be vetted manually for type safety.
@ -3489,7 +3482,7 @@ The package "unsafe" provides (at least) the following package interface:
package unsafe
const Maxalign
const Maxalign int
type Pointer *any
@ -3532,6 +3525,9 @@ a variable "x" of the largest arithmetic type (8 for a float64), but may
be smaller on systems that have less stringent alignment restrictions
or are space constrained.
The results of calls to "unsafe.Alignof", "unsafe.Offsetof", and
"unsafe.Sizeof" are compile-time constants.
Size and alignment guarantees
----