blob: c210f3cbc3db46c6e4d77ddb2f51a13482b5552b [file] [log] [blame] [view]
Andrew Gerrand5bc444d2014-12-10 11:35:11 +11001# Go 1.1 "gotchas"
2
3While Go 1.1 is compatible with Go 1.0, the [compatibility promise](http://golang.org/doc/go1compat.html) permits the Go authors to break existing programs if they were incorrect in the first place.
4
5Here are a few ways in which the bug fixes in Go 1.1 may have broken your Go programs.
6
7
8## Unknown foo.Bar field in struct literal
9
10Struct field names must not include package qualifiers.
11For example, take this struct with an embedded ` *bytes.Buffer ` field:
12
13```
Dave Day0d6986a2014-12-10 15:02:18 +110014type S struct {
15 *bytes.Buffer
16}
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110017```
18
19In Go 1.0 the compiler would (incorrectly) accept this struct literal:
20
21```
Dave Day0d6986a2014-12-10 15:02:18 +110022s := S{
23 bytes.Buffer: new(bytes.Buffer),
24}
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110025```
26
27Under Go 1.1 the compiler rejects this.
28Instead you should use the field name without the package qualifier:
29
30```
Dave Day0d6986a2014-12-10 15:02:18 +110031s := S{
32 Buffer: new(bytes.Buffer),
33}
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110034```
35
36## Initialization loop
37
38The Go 1.1 compiler now better detects initialization loops.
39
40For instance, the following code compiled under Go 1.0.
41
42```
Dave Day0d6986a2014-12-10 15:02:18 +110043var funcVar = fn
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110044
Dave Day0d6986a2014-12-10 15:02:18 +110045func fn() {
46 funcVar()
47}
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110048```
49
50Such code must now use an ` init ` function for the variable assignment to avoid
51the initialization loop.
52
53```
Dave Day0d6986a2014-12-10 15:02:18 +110054var funcVar func()
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110055
Dave Day0d6986a2014-12-10 15:02:18 +110056func fn() {
57 funcVar()
58}
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110059
Dave Day0d6986a2014-12-10 15:02:18 +110060func init() {
61 funcVar = fn
62}
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110063```
64
65In particular, this affects users of App Engine's [delay package](https://developers.google.com/appengine/docs/go/taskqueue/delay).
66
67
68## Cannot fallthrough final case in switch
69
70Go 1.0 permitted fallthrough in the final case of a switch statement:
71
72```
Dave Day0d6986a2014-12-10 15:02:18 +110073switch {
74case false:
75 fallthrough // fall through to 'true' case
76case true:
77 fallthrough // fall through to... nowhere?
78}
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110079```
80
81A language change affecting [return requirements](http://golang.org/doc/go1.1#return) led us to make the superfluous fallthrough illegal.
82
83The fix is to remove such statements from your code.
84
85
86## Duplicate argument name in parameters and return values
87
88A compiler bug permitted function type declarations with parameters and return values of the same name. This would compile under Go 1.0:
89
90```
Dave Day0d6986a2014-12-10 15:02:18 +110091type T func(a int) (a int)
Andrew Gerrand5bc444d2014-12-10 11:35:11 +110092```
93
94Under Go 1.1, the compiler gives an error:
95
96```
97 duplicate argument a
98```
99
100The fix is to rename the arguments so that they use different names.
101
102
103## Package "go" forbidden
104
105The import path "go" is now reserved. If you have a package in your workspace
106whose import path is "go", you will need to rename it and move it somewhere
107else.
108
109While it was permitted, it is a bad idea to use this import path.
110The standard library includes "go/parser", "go/ast", and so on.
111It's posssible that a "go" package might be introduced in a future Go release,
112making your "go" package unusable.
113
114Please read [How to write Go code](http://golang.org/doc/code.html) for more
115details about importh paths.