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:
parent
5f4f5647ef
commit
6f8df7aa3e
@ -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
|
||||
----
|
||||
|
Loading…
Reference in New Issue
Block a user