Home | History | Annotate | Download | only in doc

Lines Matching full:that

22 It is intended that programs written to the Go 1 specification will
24 of that specification. At some indefinite point, a Go 2 specification
25 may arise, but until that time, Go programs that work today should
39 a way that breaks existing Go 1 code.
45 Although we expect that the vast majority of programs will maintain
46 this compatibility over time, it is impossible to guarantee that
49 future. There are a number of ways in which a program that compiles
64 that are undefined. Programs that depend on such unspecified behavior
78 Bugs. If a compiler or library has a bug that violates the
79 specification, a program that depends on the buggy behavior may
86 the API. Code that uses unkeyed struct literals (such as pkg.T{3,
88 such a change. However, code that uses keyed literals (pkg.T{A:
90 update such data structures in a way that allows keyed struct
94 We therefore recommend that composite literals whose type is defined
120 Use of package <code>unsafe</code>. Packages that import
124 that may break such programs.
137 instance, code that runs under Go 1.2 should be compatible with Go
151 that the performance of a program may be affected by
171 will be tagged as appropriate to identify versions that are compatible
195 means, for instance, that scripts that depend on the location and
200 These caveats aside, we believe that Go 1 will be a firm foundation