go command for building Go programs and the new binary
release process being introduced. Most of these topics have more
thorough presentations elsewhere; such documents are linked below.
+
+The append built-in function is variadic, so one can
+append to a byte slice using the ... syntax in the
+call.
+
greeting := []byte{}
+ greeting = append(greeting, []byte("hello ")...)
+
+
+
+By analogy with the similar property of copy, Go 1
+permits a string to be appended (byte-wise) directly to a byte
+slice; the conversion is no longer necessary:
+
greeting = append(greeting, "world"...) ++ +
+Updating: +This is a new feature, so existing code needs no changes. +
+
+The close built-in function lets a sender tell a receiver
+that no more data will be transmitted on the channel. In Go 1 the
+type system enforces the directionality when possible: it is illegal
+to call close on a receive-only channel:
+
+ var c chan int + var csend chan<- int = c + var crecv <-chan int = c + close(c) // legal + close(csend) // legal + close(crecv) // illegal ++ +
+Updating: +Existing code that attempts to close a receive-only channel was +erroneous even before Go 1 and should be fixed. The compiler will +now reject such code. +
+
+Go 1 allows goroutines to be created and run during initialization.
+(They used to be created but were not run until after initialization
+completed.) Code that uses goroutines can now be called from
+init routines and global initialization expressions
+without introducing a deadlock.
+
var PackageGlobal int
+
+func init() {
+ c := make(chan int)
+ go initializationFunction(c)
+ PackageGlobal = <-c
+}
+
+
+
+Updating:
+This is a new feature, so existing code needs no changes,
+although it's possible that code that depends on goroutines not starting before main will break.
+There was no such code in the standard repository.
+
+In Go 1, the order in which elements are visited when iterating
+over a map using a for range statement
+is defined to be unpredictable, even if the same loop is run multiple
+times with the same map.
+Code should not assume that the elements are visited in any particular order.
+
m := map[string]int{"Sunday": 0, "Monday": 1}
+ for name, value := range m {
+ // This loop should not assume Sunday will be visited first.
+ f(name, value)
+ }
+
+
++Updating: +This is one change where tools cannot help. Most existing code +will be unaffected, but some programs may break or misbehave; we +recommend manual checking of all range statements over maps to +verify they do not depend on iteration order. There were a few such +examples in the standard repository; they have been fixed. +Note that it was already incorrect to depend on the iteration order, which +was unspecified. This change codifies the unpredictability. +
+Go 1 fully specifies the evaluation order in multiple assignment +statements. In particular, if the left-hand side of the assignment +statement contains expressions that require evaluation, such as +function calls or array indexing operations, these will all be done +using the usual left-to-right rule before any variables are assigned +their value. Once everything is evaluated, the actual assignments +proceed in left-to-right order. +
+ ++These examples illustrate the behavior. +
+ + sa := []int{1, 2, 3}
+ i := 0
+ i, sa[i] = 1, 2 // sets i = 1, sa[0] = 2
+
+ sb := []int{1, 2, 3}
+ j := 0
+ sb[j], j = 2, 1 // sets sb[0] = 2, j = 1
+
+ sc := []int{1, 2, 3}
+ sc[0], sc[0] = 1, 2 // sets sc[0] = 1, then sc[0] = 2 (so sc[0] = 2 at end)
+
+
+Updating:
+This is one change where tools cannot help, but breakage is unlikely.
+No code in the standard repository was broken by this change, and code
+that depended on the previous unspecified behavior was already incorrect.
+
+
+A shadowed variable is one that has the same name as another variable in an inner scope. +In functions with named return values, +the Go 1 compilers disallow return statements without arguments if any of the named return values is shadowed at the point of the return statement. +(It isn't part of the specification, because this is one area we are still exploring; +the situation is analogous to the compilers rejecting functions that do not end with an explicit return statement.) +
+ ++This function implicitly returns a shadowed return value and will be rejected by the compiler: +
+ +
+ func Bug() (i, j, k int) {
+ for i = 0; i < 5; i++ {
+ for j := 0; j < 5; j++ { // Redeclares j.
+ k += i*j
+ if k > 100 {
+ return // Rejected: j is shadowed here.
+ }
+ }
+ }
+ return // OK: j is not shadowed here.
+ }
+
+
++Updating: +Code that shadows return values in this way will be rejected by the compiler and will need to be fixed by hand. +The few cases that arose in the standard repository were mostly bugs. +
+ +
+Go 1 defines equality and inequality (== and
+!=) for struct and array values, respectively, provided
+the elements of the data structures can themselves be compared.
+That is, if equality is defined for all the fields of a struct (or
+an array element), then it is defined for the struct (or array).
+
+As a result, structs and arrays can now be used as map keys: +
+ + // type Day struct {
+ // long string
+ // short string
+ // }
+ // Christmas := Day{"Christmas", "XMas"}
+ // Thanksgiving := Day{"Thanksgiving", "Turkey"}
+ // holiday := map[Day]bool {
+ // Christmas: true,
+ // Thanksgiving: true,
+ // }
+ // fmt.Printf("Christmas is a holiday: %t\n", holiday[Christmas])
+
+
+
+Note that equality is still undefined for slices, for which the
+calculation is in general infeasible. Also note that the ordered
+comparison operators (< <=
+> >=) are still undefined for
+structs and arrays.
+
+
+Updating: +This is a new feature, so existing code needs no changes. +
+ +
+Go 1 disallows checking for equality of functions and maps,
+respectively, except to compare them directly to nil.
+
+Updating: +Existing code that depends on function or map equality will be +rejected by the compiler and will need to be fixed by hand. +Few programs will be affected, but the fix may require some +redesign. +
+go command for building Go programs and the new binary
release process being introduced. Most of these topics have more
thorough presentations elsewhere; such documents are linked below.
+
+The append built-in function is variadic, so one can
+append to a byte slice using the ... syntax in the
+call.
+
+By analogy with the similar property of copy, Go 1
+permits a string to be appended (byte-wise) directly to a byte
+slice; the conversion is no longer necessary:
+
+Updating: +This is a new feature, so existing code needs no changes. +
+
+The close built-in function lets a sender tell a receiver
+that no more data will be transmitted on the channel. In Go 1 the
+type system enforces the directionality when possible: it is illegal
+to call close on a receive-only channel:
+
+ var c chan int + var csend chan<- int = c + var crecv <-chan int = c + close(c) // legal + close(csend) // legal + close(crecv) // illegal ++ +
+Updating: +Existing code that attempts to close a receive-only channel was +erroneous even before Go 1 and should be fixed. The compiler will +now reject such code. +
+
+Go 1 allows goroutines to be created and run during initialization.
+(They used to be created but were not run until after initialization
+completed.) Code that uses goroutines can now be called from
+init routines and global initialization expressions
+without introducing a deadlock.
+
+Updating:
+This is a new feature, so existing code needs no changes,
+although it's possible that code that depends on goroutines not starting before main will break.
+There was no such code in the standard repository.
+
+In Go 1, the order in which elements are visited when iterating
+over a map using a for range statement
+is defined to be unpredictable, even if the same loop is run multiple
+times with the same map.
+Code should not assume that the elements are visited in any particular order.
+
+Updating: +This is one change where tools cannot help. Most existing code +will be unaffected, but some programs may break or misbehave; we +recommend manual checking of all range statements over maps to +verify they do not depend on iteration order. There were a few such +examples in the standard repository; they have been fixed. +Note that it was already incorrect to depend on the iteration order, which +was unspecified. This change codifies the unpredictability. +
+Go 1 fully specifies the evaluation order in multiple assignment +statements. In particular, if the left-hand side of the assignment +statement contains expressions that require evaluation, such as +function calls or array indexing operations, these will all be done +using the usual left-to-right rule before any variables are assigned +their value. Once everything is evaluated, the actual assignments +proceed in left-to-right order. +
+ ++These examples illustrate the behavior. +
+ +{{code "progs/go1.go" `/sa :=/` `/then sc.0. = 2/`}} + +Updating: +This is one change where tools cannot help, but breakage is unlikely. +No code in the standard repository was broken by this change, and code +that depended on the previous unspecified behavior was already incorrect. + ++A shadowed variable is one that has the same name as another variable in an inner scope. +In functions with named return values, +the Go 1 compilers disallow return statements without arguments if any of the named return values is shadowed at the point of the return statement. +(It isn't part of the specification, because this is one area we are still exploring; +the situation is analogous to the compilers rejecting functions that do not end with an explicit return statement.) +
+ ++This function implicitly returns a shadowed return value and will be rejected by the compiler: +
+ +
+ func Bug() (i, j, k int) {
+ for i = 0; i < 5; i++ {
+ for j := 0; j < 5; j++ { // Redeclares j.
+ k += i*j
+ if k > 100 {
+ return // Rejected: j is shadowed here.
+ }
+ }
+ }
+ return // OK: j is not shadowed here.
+ }
+
+
++Updating: +Code that shadows return values in this way will be rejected by the compiler and will need to be fixed by hand. +The few cases that arose in the standard repository were mostly bugs. +
+ +
+Go 1 defines equality and inequality (== and
+!=) for struct and array values, respectively, provided
+the elements of the data structures can themselves be compared.
+That is, if equality is defined for all the fields of a struct (or
+an array element), then it is defined for the struct (or array).
+
+As a result, structs and arrays can now be used as map keys: +
+ +{{code "progs/go1.go" `/type Day struct/` `/Printf/`}} + +
+Note that equality is still undefined for slices, for which the
+calculation is in general infeasible. Also note that the ordered
+comparison operators (< <=
+> >=) are still undefined for
+structs and arrays.
+
+
+Updating: +This is a new feature, so existing code needs no changes. +
+ +
+Go 1 disallows checking for equality of functions and maps,
+respectively, except to compare them directly to nil.
+
+Updating: +Existing code that depends on function or map equality will be +rejected by the compiler and will need to be fixed by hand. +Few programs will be affected, but the fix may require some +redesign. +
+