Home | History | Annotate | Download | only in doc
      1 <!--{
      2 	"Title": "Go 1.2 Release Notes",
      3 	"Path":  "/doc/go1.2",
      4 	"Template": true
      5 }-->
      6 
      7 <h2 id="introduction">Introduction to Go 1.2</h2>
      8 
      9 <p>
     10 Since the release of <a href="/doc/go1.1.html">Go version 1.1</a> in April, 2013,
     11 the release schedule has been shortened to make the release process more efficient.
     12 This release, Go version 1.2 or Go 1.2 for short, arrives roughly six months after 1.1,
     13 while 1.1 took over a year to appear after 1.0.
     14 Because of the shorter time scale, 1.2 is a smaller delta than the step from 1.0 to 1.1,
     15 but it still has some significant developments, including
     16 a better scheduler and one new language feature.
     17 Of course, Go 1.2 keeps the <a href="/doc/go1compat.html">promise
     18 of compatibility</a>.
     19 The overwhelming majority of programs built with Go 1.1 (or 1.0 for that matter)
     20 will run without any changes whatsoever when moved to 1.2,
     21 although the introduction of one restriction
     22 to a corner of the language may expose already-incorrect code
     23 (see the discussion of the <a href="#use_of_nil">use of nil</a>).
     24 </p>
     25 
     26 <h2 id="language">Changes to the language</h2>
     27 
     28 <p>
     29 In the interest of firming up the specification, one corner case has been clarified,
     30 with consequences for programs.
     31 There is also one new language feature.
     32 </p>
     33 
     34 <h3 id="use_of_nil">Use of nil</h3>
     35 
     36 <p>
     37 The language now specifies that, for safety reasons,
     38 certain uses of nil pointers are guaranteed to trigger a run-time panic.
     39 For instance, in Go 1.0, given code like
     40 </p>
     41 
     42 <pre>
     43 type T struct {
     44     X [1<<24]byte
     45     Field int32
     46 }
     47 
     48 func main() {
     49     var x *T
     50     ...
     51 }
     52 </pre>
     53 
     54 <p>
     55 the <code>nil</code> pointer <code>x</code> could be used to access memory incorrectly:
     56 the expression <code>x.Field</code> could access memory at address <code>1<<24</code>.
     57 To prevent such unsafe behavior, in Go 1.2 the compilers now guarantee that any indirection through
     58 a nil pointer, such as illustrated here but also in nil pointers to arrays, nil interface values,
     59 nil slices, and so on, will either panic or return a correct, safe non-nil value.
     60 In short, any expression that explicitly or implicitly requires evaluation of a nil address is an error.
     61 The implementation may inject extra tests into the compiled program to enforce this behavior.
     62 </p>
     63 
     64 <p>
     65 Further details are in the
     66 <a href="//golang.org/s/go12nil">design document</a>.
     67 </p>
     68 
     69 <p>
     70 <em>Updating</em>:
     71 Most code that depended on the old behavior is erroneous and will fail when run.
     72 Such programs will need to be updated by hand.
     73 </p>
     74 
     75 <h3 id="three_index">Three-index slices</h3>
     76 
     77 <p>
     78 Go 1.2 adds the ability to specify the capacity as well as the length when using a slicing operation
     79 on an existing array or slice.
     80 A slicing operation creates a new slice by describing a contiguous section of an already-created array or slice:
     81 </p>
     82 
     83 <pre>
     84 var array [10]int
     85 slice := array[2:4]
     86 </pre>
     87 
     88 <p>
     89 The capacity of the slice is the maximum number of elements that the slice may hold, even after reslicing;
     90 it reflects the size of the underlying array.
     91 In this example, the capacity of the <code>slice</code> variable is 8.
     92 </p>
     93 
     94 <p>
     95 Go 1.2 adds new syntax to allow a slicing operation to specify the capacity as well as the length.
     96 A second
     97 colon introduces the capacity value, which must be less than or equal to the capacity of the
     98 source slice or array, adjusted for the origin. For instance,
     99 </p>
    100 
    101 <pre>
    102 slice = array[2:4:7]
    103 </pre>
    104 
    105 <p>
    106 sets the slice to have the same length as in the earlier example but its capacity is now only 5 elements (7-2).
    107 It is impossible to use this new slice value to access the last three elements of the original array.
    108 </p>
    109 
    110 <p>
    111 In this three-index notation, a missing first index (<code>[:i:j]</code>) defaults to zero but the other
    112 two indices must always be specified explicitly.
    113 It is possible that future releases of Go may introduce default values for these indices.
    114 </p>
    115 
    116 <p>
    117 Further details are in the
    118 <a href="//golang.org/s/go12slice">design document</a>.
    119 </p>
    120 
    121 <p>
    122 <em>Updating</em>:
    123 This is a backwards-compatible change that affects no existing programs.
    124 </p>
    125 
    126 <h2 id="impl">Changes to the implementations and tools</h2>
    127 
    128 <h3 id="preemption">Pre-emption in the scheduler</h3>
    129 
    130 <p>
    131 In prior releases, a goroutine that was looping forever could starve out other
    132 goroutines on the same thread, a serious problem when GOMAXPROCS
    133 provided only one user thread.
    134 In Go 1.2, this is partially addressed: The scheduler is invoked occasionally
    135 upon entry to a function.
    136 This means that any loop that includes a (non-inlined) function call can
    137 be pre-empted, allowing other goroutines to run on the same thread.
    138 </p>
    139 
    140 <h3 id="thread_limit">Limit on the number of threads</h3>
    141 
    142 <p>
    143 Go 1.2 introduces a configurable limit (default 10,000) to the total number of threads
    144 a single program may have in its address space, to avoid resource starvation
    145 issues in some environments.
    146 Note that goroutines are multiplexed onto threads so this limit does not directly
    147 limit the number of goroutines, only the number that may be simultaneously blocked
    148 in a system call.
    149 In practice, the limit is hard to reach.
    150 </p>
    151 
    152 <p>
    153 The new <a href="/pkg/runtime/debug/#SetMaxThreads"><code>SetMaxThreads</code></a> function in the
    154 <a href="/pkg/runtime/debug/"><code>runtime/debug</code></a> package controls the thread count limit.
    155 </p>
    156 
    157 <p>
    158 <em>Updating</em>:
    159 Few functions will be affected by the limit, but if a program dies because it hits the
    160 limit, it could be modified to call <code>SetMaxThreads</code> to set a higher count.
    161 Even better would be to refactor the program to need fewer threads, reducing consumption
    162 of kernel resources.
    163 </p>
    164 
    165 <h3 id="stack_size">Stack size</h3>
    166 
    167 <p>
    168 In Go 1.2, the minimum size of the stack when a goroutine is created has been lifted from 4KB to 8KB.
    169 Many programs were suffering performance problems with the old size, which had a tendency
    170 to introduce expensive stack-segment switching in performance-critical sections.
    171 The new number was determined by empirical testing.
    172 </p>
    173 
    174 <p>
    175 At the other end, the new function <a href="/pkg/runtime/debug/#SetMaxStack"><code>SetMaxStack</code></a>
    176 in the <a href="/pkg/runtime/debug"><code>runtime/debug</code></a> package controls
    177 the <em>maximum</em> size of a single goroutine's stack.
    178 The default is 1GB on 64-bit systems and 250MB on 32-bit systems.
    179 Before Go 1.2, it was too easy for a runaway recursion to consume all the memory on a machine.
    180 </p>
    181 
    182 <p>
    183 <em>Updating</em>:
    184 The increased minimum stack size may cause programs with many goroutines to use
    185 more memory. There is no workaround, but plans for future releases
    186 include new stack management technology that should address the problem better.
    187 </p>
    188 
    189 <h3 id="cgo_and_cpp">Cgo and C++</h3>
    190 
    191 <p>
    192 The <a href="/cmd/cgo/"><code>cgo</code></a> command will now invoke the C++
    193 compiler to build any pieces of the linked-to library that are written in C++;
    194 <a href="/cmd/cgo/">the documentation</a> has more detail.
    195 </p>
    196 
    197 <h3 id="go_tools_godoc">Godoc and vet moved to the go.tools subrepository</h3>
    198 
    199 <p>
    200 Both binaries are still included with the distribution, but the source code for the
    201 godoc and vet commands has moved to the
    202 <a href="//code.google.com/p/go.tools">go.tools</a> subrepository.
    203 </p>
    204 
    205 <p>
    206 Also, the core of the godoc program has been split into a
    207 <a href="https://code.google.com/p/go/source/browse/?repo=tools#hg%2Fgodoc">library</a>,
    208 while the command itself is in a separate
    209 <a href="https://code.google.com/p/go/source/browse/?repo=tools#hg%2Fcmd%2Fgodoc">directory</a>.
    210 The move allows the code to be updated easily and the separation into a library and command
    211 makes it easier to construct custom binaries for local sites and different deployment methods.
    212 </p>
    213 
    214 <p>
    215 <em>Updating</em>:
    216 Since godoc and vet are not part of the library,
    217 no client Go code depends on the their source and no updating is required.
    218 </p>
    219 
    220 <p>
    221 The binary distributions available from <a href="//golang.org">golang.org</a>
    222 include these binaries, so users of these distributions are unaffected.
    223 </p>
    224 
    225 <p>
    226 When building from source, users must use "go get" to install godoc and vet.
    227 (The binaries will continue to be installed in their usual locations, not
    228 <code>$GOPATH/bin</code>.)
    229 </p>
    230 
    231 <pre>
    232 $ go get code.google.com/p/go.tools/cmd/godoc
    233 $ go get code.google.com/p/go.tools/cmd/vet
    234 </pre>
    235 
    236 <h3 id="gccgo">Status of gccgo</h3>
    237 
    238 <p>
    239 We expect the future GCC 4.9 release to include gccgo with full
    240 support for Go 1.2.
    241 In the current (4.8.2) release of GCC, gccgo implements Go 1.1.2.
    242 </p>
    243 
    244 <h3 id="gc_changes">Changes to the gc compiler and linker</h3>
    245 
    246 <p>
    247 Go 1.2 has several semantic changes to the workings of the gc compiler suite.
    248 Most users will be unaffected by them.
    249 </p>
    250 
    251 <p>
    252 The <a href="/cmd/cgo/"><code>cgo</code></a> command now
    253 works when C++ is included in the library being linked against.
    254 See the <a href="/cmd/cgo/"><code>cgo</code></a> documentation
    255 for details.
    256 </p>
    257 
    258 <p>
    259 The gc compiler displayed a vestigial detail of its origins when
    260 a program had no <code>package</code> clause: it assumed
    261 the file was in package <code>main</code>.
    262 The past has been erased, and a missing <code>package</code> clause
    263 is now an error.
    264 </p>
    265 
    266 <p>
    267 On the ARM, the toolchain supports "external linking", which
    268 is a step towards being able to build shared libraries with the gc
    269 tool chain and to provide dynamic linking support for environments
    270 in which that is necessary.
    271 </p>
    272 
    273 <p>
    274 In the runtime for the ARM, with <code>5a</code>, it used to be possible to refer
    275 to the runtime-internal <code>m</code> (machine) and <code>g</code>
    276 (goroutine) variables using <code>R9</code> and <code>R10</code> directly.
    277 It is now necessary to refer to them by their proper names.
    278 </p>
    279 
    280 <p>
    281 Also on the ARM, the <code>5l</code> linker (sic) now defines the
    282 <code>MOVBS</code> and <code>MOVHS</code> instructions
    283 as synonyms of <code>MOVB</code> and <code>MOVH</code>,
    284 to make clearer the separation between signed and unsigned
    285 sub-word moves; the unsigned versions already existed with a
    286 <code>U</code> suffix.
    287 </p>
    288 
    289 <h3 id="cover">Test coverage</h3>
    290 
    291 <p>
    292 One major new feature of <a href="/pkg/go/"><code>go test</code></a> is
    293 that it can now compute and, with help from a new, separately installed
    294 "go tool cover" program, display test coverage results.
    295 </p>
    296 
    297 <p>
    298 The cover tool is part of the
    299 <a href="https://code.google.com/p/go/source/checkout?repo=tools"><code>go.tools</code></a>
    300 subrepository.
    301 It can be installed by running
    302 </p>
    303 
    304 <pre>
    305 $ go get code.google.com/p/go.tools/cmd/cover
    306 </pre>
    307 
    308 <p>
    309 The cover tool does two things.
    310 First, when "go test" is given the <code>-cover</code> flag, it is run automatically 
    311 to rewrite the source for the package and insert instrumentation statements.
    312 The test is then compiled and run as usual, and basic coverage statistics are reported:
    313 </p>
    314 
    315 <pre>
    316 $ go test -cover fmt
    317 ok  	fmt	0.060s	coverage: 91.4% of statements
    318 $
    319 </pre>
    320 
    321 <p>
    322 Second, for more detailed reports, different flags to "go test" can create a coverage profile file,
    323 which the cover program, invoked with "go tool cover", can then analyze.
    324 </p>
    325 
    326 <p>
    327 Details on how to generate and analyze coverage statistics can be found by running the commands
    328 </p>
    329 
    330 <pre>
    331 $ go help testflag
    332 $ go tool cover -help
    333 </pre>
    334 
    335 <h3 id="go_doc">The go doc command is deleted</h3>
    336 
    337 <p>
    338 The "go doc" command is deleted.
    339 Note that the <a href="/cmd/godoc/"><code>godoc</code></a> tool itself is not deleted,
    340 just the wrapping of it by the <a href="/cmd/go/"><code>go</code></a> command.
    341 All it did was show the documents for a package by package path,
    342 which godoc itself already does with more flexibility.
    343 It has therefore been deleted to reduce the number of documentation tools and,
    344 as part of the restructuring of godoc, encourage better options in future.
    345 </p>
    346 
    347 <p>
    348 <em>Updating</em>: For those who still need the precise functionality of running
    349 </p>
    350 
    351 <pre>
    352 $ go doc
    353 </pre>
    354 
    355 <p>
    356 in a directory, the behavior is identical to running
    357 </p>
    358 
    359 <pre>
    360 $ godoc .
    361 </pre>
    362 
    363 <h3 id="gocmd">Changes to the go command</h3>
    364 
    365 <p>
    366 The <a href="/cmd/go/"><code>go get</code></a> command
    367 now has a <code>-t</code> flag that causes it to download the dependencies
    368 of the tests run by the package, not just those of the package itself.
    369 By default, as before, dependencies of the tests are not downloaded.
    370 </p>
    371 
    372 <h2 id="performance">Performance</h2>
    373 
    374 <p>
    375 There are a number of significant performance improvements in the standard library; here are a few of them.
    376 </p>
    377 
    378 <ul> 
    379 
    380 <li>
    381 The <a href="/pkg/compress/bzip2/"><code>compress/bzip2</code></a>
    382 decompresses about 30% faster.
    383 </li>
    384 
    385 <li>
    386 The <a href="/pkg/crypto/des/"><code>crypto/des</code></a> package
    387 is about five times faster.
    388 </li>
    389 
    390 <li>
    391 The <a href="/pkg/encoding/json/"><code>encoding/json</code></a> package
    392 encodes about 30% faster.
    393 </li>
    394 
    395 <li>
    396 Networking performance on Windows and BSD systems is about 30% faster through the use
    397 of an integrated network poller in the runtime, similar to what was done for Linux and OS X
    398 in Go 1.1.
    399 </li>
    400 
    401 </ul>
    402 
    403 <h2 id="library">Changes to the standard library</h2>
    404 
    405 
    406 <h3 id="archive_tar_zip">The archive/tar and archive/zip packages</h3>
    407 
    408 <p>
    409 The
    410 <a href="/pkg/archive/tar/"><code>archive/tar</code></a>
    411 and
    412 <a href="/pkg/archive/zip/"><code>archive/zip</code></a>
    413 packages have had a change to their semantics that may break existing programs.
    414 The issue is that they both provided an implementation of the
    415 <a href="/pkg/os/#FileInfo"><code>os.FileInfo</code></a>
    416 interface that was not compliant with the specification for that interface.
    417 In particular, their <code>Name</code> method returned the full
    418 path name of the entry, but the interface specification requires that
    419 the method return only the base name (final path element).
    420 </p>
    421 
    422 <p>
    423 <em>Updating</em>: Since this behavior was newly implemented and
    424 a bit obscure, it is possible that no code depends on the broken behavior.
    425 If there are programs that do depend on it, they will need to be identified
    426 and fixed manually.
    427 </p>
    428 
    429 <h3 id="encoding">The new encoding package</h3>
    430 
    431 <p>
    432 There is a new package, <a href="/pkg/encoding/"><code>encoding</code></a>,
    433 that defines a set of standard encoding interfaces that may be used to
    434 build custom marshalers and unmarshalers for packages such as
    435 <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a>,
    436 <a href="/pkg/encoding/json/"><code>encoding/json</code></a>,
    437 and
    438 <a href="/pkg/encoding/binary/"><code>encoding/binary</code></a>.
    439 These new interfaces have been used to tidy up some implementations in
    440 the standard library.
    441 </p>
    442 
    443 <p>
    444 The new interfaces are called
    445 <a href="/pkg/encoding/#BinaryMarshaler"><code>BinaryMarshaler</code></a>,
    446 <a href="/pkg/encoding/#BinaryUnmarshaler"><code>BinaryUnmarshaler</code></a>,
    447 <a href="/pkg/encoding/#TextMarshaler"><code>TextMarshaler</code></a>,
    448 and
    449 <a href="/pkg/encoding/#TextUnmarshaler"><code>TextUnmarshaler</code></a>.
    450 Full details are in the <a href="/pkg/encoding/">documentation</a> for the package
    451 and a separate <a href="//golang.org/s/go12encoding">design document</a>.
    452 </p>
    453 
    454 <h3 id="fmt_indexed_arguments">The fmt package</h3>
    455 
    456 <p>
    457 The <a href="/pkg/fmt/"><code>fmt</code></a> package's formatted print
    458 routines such as <a href="/pkg/fmt/#Printf"><code>Printf</code></a>
    459 now allow the data items to be printed to be accessed in arbitrary order
    460 by using an indexing operation in the formatting specifications.
    461 Wherever an argument is to be fetched from the argument list for formatting,
    462 either as the value to be formatted or as a width or specification integer,
    463 a new optional indexing notation <code>[</code><em>n</em><code>]</code>
    464 fetches argument <em>n</em> instead.
    465 The value of <em>n</em> is 1-indexed.
    466 After such an indexing operating, the next argument to be fetched by normal
    467 processing will be <em>n</em>+1.
    468 </p>
    469 
    470 <p>
    471 For example, the normal <code>Printf</code> call
    472 </p>
    473 
    474 <pre>
    475 fmt.Sprintf("%c %c %c\n", 'a', 'b', 'c')
    476 </pre>
    477 
    478 <p>
    479 would create the string <code>"a b c"</code>, but with indexing operations like this,
    480 </p>
    481 
    482 <pre>
    483 fmt.Sprintf("%[3]c %[1]c %c\n", 'a', 'b', 'c')
    484 </pre>
    485 
    486 <p>
    487 the result is "<code>"c a b"</code>. The <code>[3]</code> index accesses the third formatting
    488 argument, which is <code>'c'</code>, <code>[1]</code> accesses the first, <code>'a'</code>,
    489 and then the next fetch accesses the argument following that one, <code>'b'</code>.
    490 </p>
    491 
    492 <p>
    493 The motivation for this feature is programmable format statements to access
    494 the arguments in different order for localization, but it has other uses:
    495 </p>
    496 
    497 <pre>
    498 log.Printf("trace: value %v of type %[1]T\n", expensiveFunction(a.b[c]))
    499 </pre>
    500 
    501 <p>
    502 <em>Updating</em>: The change to the syntax of format specifications
    503 is strictly backwards compatible, so it affects no working programs.
    504 </p>
    505 
    506 <h3 id="text_template">The text/template and html/template packages</h3>
    507 
    508 <p>
    509 The
    510 <a href="/pkg/text/template/"><code>text/template</code></a> package
    511 has a couple of changes in Go 1.2, both of which are also mirrored in the
    512 <a href="/pkg/html/template/"><code>html/template</code></a> package.
    513 </p>
    514 
    515 <p>
    516 First, there are new default functions for comparing basic types.
    517 The functions are listed in this table, which shows their names and
    518 the associated familiar comparison operator.
    519 </p>
    520 
    521 <table cellpadding="0" summary="Template comparison functions">
    522 <tr>
    523 <th width="50"></th><th width="100">Name</th> <th width="50">Operator</th>
    524 </tr>
    525 <tr>
    526 <td></td><td><code>eq</code></td> <td><code>==</code></td>
    527 </tr>
    528 <tr>
    529 <td></td><td><code>ne</code></td> <td><code>!=</code></td>
    530 </tr>
    531 <tr>
    532 <td></td><td><code>lt</code></td> <td><code>&lt;</code></td>
    533 </tr>
    534 <tr>
    535 <td></td><td><code>le</code></td> <td><code>&lt;=</code></td>
    536 </tr>
    537 <tr>
    538 <td></td><td><code>gt</code></td> <td><code>&gt;</code></td>
    539 </tr>
    540 <tr>
    541 <td></td><td><code>ge</code></td> <td><code>&gt;=</code></td>
    542 </tr>
    543 </table>
    544 
    545 <p>
    546 These functions behave slightly differently from the corresponding Go operators.
    547 First, they operate only on basic types (<code>bool</code>, <code>int</code>,
    548 <code>float64</code>, <code>string</code>, etc.).
    549 (Go allows comparison of arrays and structs as well, under some circumstances.)
    550 Second, values can be compared as long as they are the same sort of value:
    551 any signed integer value can be compared to any other signed integer value for example. (Go
    552 does not permit comparing an <code>int8</code> and an <code>int16</code>).
    553 Finally, the <code>eq</code> function (only) allows comparison of the first
    554 argument with one or more following arguments. The template in this example,
    555 </p>
    556 
    557 <pre>
    558 {{"{{"}}if eq .A 1 2 3 {{"}}"}} equal {{"{{"}}else{{"}}"}} not equal {{"{{"}}end{{"}}"}}
    559 </pre>
    560 
    561 <p>
    562 reports "equal" if <code>.A</code> is equal to <em>any</em> of 1, 2, or 3.
    563 </p>
    564 
    565 <p>
    566 The second change is that a small addition to the grammar makes "if else if" chains easier to write.
    567 Instead of writing,
    568 </p>
    569 
    570 <pre>
    571 {{"{{"}}if eq .A 1{{"}}"}} X {{"{{"}}else{{"}}"}} {{"{{"}}if eq .A 2{{"}}"}} Y {{"{{"}}end{{"}}"}} {{"{{"}}end{{"}}"}} 
    572 </pre>
    573 
    574 <p>
    575 one can fold the second "if" into the "else" and have only one "end", like this:
    576 </p>
    577 
    578 <pre>
    579 {{"{{"}}if eq .A 1{{"}}"}} X {{"{{"}}else if eq .A 2{{"}}"}} Y {{"{{"}}end{{"}}"}}
    580 </pre>
    581 
    582 <p>
    583 The two forms are identical in effect; the difference is just in the syntax.
    584 </p>
    585 
    586 <p>
    587 <em>Updating</em>: Neither the "else if" change nor the comparison functions
    588 affect existing programs. Those that
    589 already define functions called <code>eq</code> and so on through a function
    590 map are unaffected because the associated function map will override the new
    591 default function definitions.
    592 </p>
    593 
    594 <h3 id="new_packages">New packages</h3>
    595 
    596 <p>
    597 There are two new packages.
    598 </p>
    599 
    600 <ul>
    601 <li>
    602 The <a href="/pkg/encoding/"><code>encoding</code></a> package is
    603 <a href="#encoding">described above</a>.
    604 </li>
    605 <li>
    606 The <a href="/pkg/image/color/palette/"><code>image/color/palette</code></a> package
    607 provides standard color palettes.
    608 </li>
    609 </ul>
    610 
    611 <h3 id="minor_library_changes">Minor changes to the library</h3>
    612 
    613 <p>
    614 The following list summarizes a number of minor changes to the library, mostly additions.
    615 See the relevant package documentation for more information about each change.
    616 </p>
    617 
    618 <ul>
    619 
    620 <li>
    621 The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package
    622 adds the
    623 <a href="/pkg/archive/zip/#File.DataOffset"><code>DataOffset</code></a> accessor
    624 to return the offset of a file's (possibly compressed) data within the archive.
    625 </li>
    626 
    627 <li>
    628 The <a href="/pkg/bufio/"><code>bufio</code></a> package
    629 adds <a href="/pkg/bufio/#Reader.Reset"><code>Reset</code></a>
    630 methods to <a href="/pkg/bufio/#Reader"><code>Reader</code></a> and
    631 <a href="/pkg/bufio/#Writer"><code>Writer</code></a>.
    632 These methods allow the <a href="/pkg/io/#Reader"><code>Readers</code></a>
    633 and <a href="/pkg/io/#Writer"><code>Writers</code></a>
    634 to be re-used on new input and output readers and writers, saving
    635 allocation overhead. 
    636 </li>
    637 
    638 <li>
    639 The <a href="/pkg/compress/bzip2/"><code>compress/bzip2</code></a>
    640 can now decompress concatenated archives.
    641 </li>
    642 
    643 <li>
    644 The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>
    645 package adds a <a href="/pkg/compress/flate/#Writer.Reset"><code>Reset</code></a> 
    646 method on the <a href="/pkg/compress/flate/#Writer"><code>Writer</code></a>,
    647 to make it possible to reduce allocation when, for instance, constructing an
    648 archive to hold multiple compressed files.
    649 </li>
    650 
    651 <li>
    652 The <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a> package's
    653 <a href="/pkg/compress/gzip/#Writer"><code>Writer</code></a> type adds a
    654 <a href="/pkg/compress/gzip/#Writer.Reset"><code>Reset</code></a>
    655 so it may be reused.
    656 </li>
    657 
    658 <li>
    659 The <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a> package's
    660 <a href="/pkg/compress/zlib/#Writer"><code>Writer</code></a> type adds a
    661 <a href="/pkg/compress/zlib/#Writer.Reset"><code>Reset</code></a>
    662 so it may be reused.
    663 </li>
    664 
    665 <li>
    666 The <a href="/pkg/container/heap/"><code>container/heap</code></a> package
    667 adds a <a href="/pkg/container/heap/#Fix"><code>Fix</code></a>
    668 method to provide a more efficient way to update an item's position in the heap.
    669 </li>
    670 
    671 <li>
    672 The <a href="/pkg/container/list/"><code>container/list</code></a> package
    673 adds the <a href="/pkg/container/list/#List.MoveBefore"><code>MoveBefore</code></a>
    674 and
    675 <a href="/pkg/container/list/#List.MoveAfter"><code>MoveAfter</code></a>
    676 methods, which implement the obvious rearrangement.
    677 </li>
    678 
    679 <li>
    680 The <a href="/pkg/crypto/cipher/"><code>crypto/cipher</code></a> package
    681 adds the a new GCM mode (Galois Counter Mode), which is almost always
    682 used with AES encryption.
    683 </li>
    684 
    685 <li>
    686 The 
    687 <a href="/pkg/crypto/md5/"><code>crypto/md5</code></a> package
    688 adds a new <a href="/pkg/crypto/md5/#Sum"><code>Sum</code></a> function
    689 to simplify hashing without sacrificing performance.
    690 </li>
    691 
    692 <li>
    693 Similarly, the 
    694 <a href="/pkg/crypto/md5/"><code>crypto/sha1</code></a> package
    695 adds a new <a href="/pkg/crypto/sha1/#Sum"><code>Sum</code></a> function.
    696 </li>
    697 
    698 <li>
    699 Also, the
    700 <a href="/pkg/crypto/sha256/"><code>crypto/sha256</code></a> package
    701 adds <a href="/pkg/crypto/sha256/#Sum256"><code>Sum256</code></a>
    702 and <a href="/pkg/crypto/sha256/#Sum224"><code>Sum224</code></a> functions.
    703 </li>
    704 
    705 <li>
    706 Finally, the <a href="/pkg/crypto/sha512/"><code>crypto/sha512</code></a> package
    707 adds <a href="/pkg/crypto/sha512/#Sum512"><code>Sum512</code></a> and
    708 <a href="/pkg/crypto/sha512/#Sum384"><code>Sum384</code></a> functions.
    709 </li>
    710 
    711 <li>
    712 The <a href="/pkg/crypto/x509/"><code>crypto/x509</code></a> package
    713 adds support for reading and writing arbitrary extensions.
    714 </li>
    715 
    716 <li>
    717 The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package adds
    718 support for TLS 1.1, 1.2 and AES-GCM.
    719 </li>
    720 
    721 <li>
    722 The <a href="/pkg/database/sql/"><code>database/sql</code></a> package adds a
    723 <a href="/pkg/database/sql/#DB.SetMaxOpenConns"><code>SetMaxOpenConns</code></a>
    724 method on <a href="/pkg/database/sql/#DB"><code>DB</code></a> to limit the
    725 number of open connections to the database.
    726 </li>
    727 
    728 <li>
    729 The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package
    730 now always allows trailing commas on fields.
    731 </li>
    732 
    733 <li>
    734 The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package
    735 now treats channel and function fields of structures as if they were unexported,
    736 even if they are not. That is, it ignores them completely. Previously they would
    737 trigger an error, which could cause unexpected compatibility problems if an
    738 embedded structure added such a field.
    739 The package also now supports the generic <code>BinaryMarshaler</code> and
    740 <code>BinaryUnmarshaler</code> interfaces of the
    741 <a href="/pkg/encoding/"><code>encoding</code></a> package
    742 described above.
    743 </li>
    744 
    745 <li>
    746 The <a href="/pkg/encoding/json/"><code>encoding/json</code></a> package
    747 now will always escape ampersands as "\u0026" when printing strings.
    748 It will now accept but correct invalid UTF-8 in
    749 <a href="/pkg/encoding/json/#Marshal"><code>Marshal</code></a>
    750 (such input was previously rejected).
    751 Finally, it now supports the generic encoding interfaces of the
    752 <a href="/pkg/encoding/"><code>encoding</code></a> package
    753 described above.
    754 </li>
    755 
    756 <li>
    757 The <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a> package
    758 now allows attributes stored in pointers to be marshaled.
    759 It also supports the generic encoding interfaces of the
    760 <a href="/pkg/encoding/"><code>encoding</code></a> package
    761 described above through the new
    762 <a href="/pkg/encoding/xml/#Marshaler"><code>Marshaler</code></a>,
    763 <a href="/pkg/encoding/xml/#Unmarshaler"><code>Unmarshaler</code></a>,
    764 and related
    765 <a href="/pkg/encoding/xml/#MarshalerAttr"><code>MarshalerAttr</code></a> and
    766 <a href="/pkg/encoding/xml/#UnmarshalerAttr"><code>UnmarshalerAttr</code></a>
    767 interfaces.
    768 The package also adds a
    769 <a href="/pkg/encoding/xml/#Encoder.Flush"><code>Flush</code></a> method
    770 to the
    771 <a href="/pkg/encoding/xml/#Encoder"><code>Encoder</code></a>
    772 type for use by custom encoders. See the documentation for
    773 <a href="/pkg/encoding/xml/#Encoder.EncodeToken"><code>EncodeToken</code></a>
    774 to see how to use it.
    775 </li>
    776 
    777 <li>
    778 The <a href="/pkg/flag/"><code>flag</code></a> package now
    779 has a <a href="/pkg/flag/#Getter"><code>Getter</code></a> interface
    780 to allow the value of a flag to be retrieved. Due to the
    781 Go 1 compatibility guidelines, this method cannot be added to the existing
    782 <a href="/pkg/flag/#Value"><code>Value</code></a>
    783 interface, but all the existing standard flag types implement it.
    784 The package also now exports the <a href="/pkg/flag/#CommandLine"><code>CommandLine</code></a>
    785 flag set, which holds the flags from the command line.
    786 </li>
    787 
    788 <li>
    789 The <a href="/pkg/go/ast/"><code>go/ast</code></a> package's
    790 <a href="/pkg/go/ast/#SliceExpr"><code>SliceExpr</code></a> struct
    791 has a new boolean field, <code>Slice3</code>, which is set to true
    792 when representing a slice expression with three indices (two colons).
    793 The default is false, representing the usual two-index form.
    794 </li>
    795 
    796 <li>
    797 The <a href="/pkg/go/build/"><code>go/build</code></a> package adds
    798 the <code>AllTags</code> field
    799 to the <a href="/pkg/go/build/#Package"><code>Package</code></a> type,
    800 to make it easier to process build tags.
    801 </li>
    802 
    803 <li>
    804 The <a href="/pkg/image/draw/"><code>image/draw</code></a> package now
    805 exports an interface, <a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>,
    806 that wraps the standard <a href="/pkg/image/draw/#Draw"><code>Draw</code></a> method.
    807 The Porter-Duff operators now implement this interface, in effect binding an operation to
    808 the draw operator rather than providing it explicitly.
    809 Given a paletted image as its destination, the new
    810 <a href="/pkg/image/draw/#FloydSteinberg"><code>FloydSteinberg</code></a>
    811 implementation of the
    812 <a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>
    813 interface will use the Floyd-Steinberg error diffusion algorithm to draw the image.
    814 To create palettes suitable for such processing, the new
    815 <a href="/pkg/image/draw/#Quantizer"><code>Quantizer</code></a> interface
    816 represents implementations of quantization algorithms that choose a palette
    817 given a full-color image.
    818 There are no implementations of this interface in the library.
    819 </li>
    820 
    821 <li>
    822 The <a href="/pkg/image/gif/"><code>image/gif</code></a> package
    823 can now create GIF files using the new
    824 <a href="/pkg/image/gif/#Encode"><code>Encode</code></a>
    825 and <a href="/pkg/image/gif/#EncodeAll"><code>EncodeAll</code></a>
    826 functions.
    827 Their options argument allows specification of an image
    828 <a href="/pkg/image/draw/#Quantizer"><code>Quantizer</code></a> to use;
    829 if it is <code>nil</code>, the generated GIF will use the 
    830 <a href="/pkg/image/color/palette/#Plan9"><code>Plan9</code></a>
    831 color map (palette) defined in the new
    832 <a href="/pkg/image/color/palette/"><code>image/color/palette</code></a> package.
    833 The options also specify a
    834 <a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>
    835 to use to create the output image;
    836 if it is <code>nil</code>, Floyd-Steinberg error diffusion is used.
    837 </li>
    838 
    839 <li>
    840 The <a href="/pkg/io/#Copy"><code>Copy</code></a> method of the
    841 <a href="/pkg/io/"><code>io</code></a> package now prioritizes its
    842 arguments differently.
    843 If one argument implements <a href="/pkg/io/#WriterTo"><code>WriterTo</code></a>
    844 and the other implements <a href="/pkg/io/#ReaderFrom"><code>ReaderFrom</code></a>,
    845 <a href="/pkg/io/#Copy"><code>Copy</code></a> will now invoke
    846 <a href="/pkg/io/#WriterTo"><code>WriterTo</code></a> to do the work,
    847 so that less intermediate buffering is required in general.
    848 </li>
    849 
    850 <li>
    851 The <a href="/pkg/net/"><code>net</code></a> package requires cgo by default
    852 because the host operating system must in general mediate network call setup.
    853 On some systems, though, it is possible to use the network without cgo, and useful
    854 to do so, for instance to avoid dynamic linking.
    855 The new build tag <code>netgo</code> (off by default) allows the construction of a
    856 <code>net</code> package in pure Go on those systems where it is possible.
    857 </li>
    858 
    859 <li>
    860 The <a href="/pkg/net/"><code>net</code></a> package adds a new field
    861 <code>DualStack</code> to the <a href="/pkg/net/#Dialer"><code>Dialer</code></a>
    862 struct for TCP connection setup using a dual IP stack as described in
    863 <a href="http://tools.ietf.org/html/rfc6555">RFC 6555</a>.
    864 </li>
    865 
    866 <li>
    867 The <a href="/pkg/net/http/"><code>net/http</code></a> package will no longer
    868 transmit cookies that are incorrect according to
    869 <a href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>.
    870 It just logs an error and sends nothing.
    871 Also,
    872 the <a href="/pkg/net/http/"><code>net/http</code></a> package's
    873 <a href="/pkg/net/http/#ReadResponse"><code>ReadResponse</code></a>
    874 function now permits the <code>*Request</code> parameter to be <code>nil</code>,
    875 whereupon it assumes a GET request.
    876 Finally, an HTTP server will now serve HEAD
    877 requests transparently, without the need for special casing in handler code.
    878 While serving a HEAD request, writes to a 
    879 <a href="/pkg/net/http/#Handler"><code>Handler</code></a>'s
    880 <a href="/pkg/net/http/#ResponseWriter"><code>ResponseWriter</code></a>
    881 are absorbed by the
    882 <a href="/pkg/net/http/#Server"><code>Server</code></a>
    883 and the client receives an empty body as required by the HTTP specification.
    884 </li>
    885 
    886 <li>
    887 The <a href="/pkg/os/exec/"><code>os/exec</code></a> package's 
    888 <a href="/pkg/os/exec/#Cmd.StdinPipe"><code>Cmd.StdinPipe</code></a> method 
    889 returns an <code>io.WriteCloser</code>, but has changed its concrete
    890 implementation from <code>*os.File</code> to an unexported type that embeds
    891 <code>*os.File</code>, and it is now safe to close the returned value.
    892 Before Go 1.2, there was an unavoidable race that this change fixes.
    893 Code that needs access to the methods of <code>*os.File</code> can use an
    894 interface type assertion, such as <code>wc.(interface{ Sync() error })</code>.
    895 </li>
    896 
    897 <li>
    898 The <a href="/pkg/runtime/"><code>runtime</code></a> package relaxes
    899 the constraints on finalizer functions in
    900 <a href="/pkg/runtime/#SetFinalizer"><code>SetFinalizer</code></a>: the
    901 actual argument can now be any type that is assignable to the formal type of
    902 the function, as is the case for any normal function call in Go.
    903 </li>
    904 
    905 <li>
    906 The <a href="/pkg/sort/"><code>sort</code></a> package has a new
    907 <a href="/pkg/sort/#Stable"><code>Stable</code></a> function that implements
    908 stable sorting. It is less efficient than the normal sort algorithm, however.
    909 </li>
    910 
    911 <li>
    912 The <a href="/pkg/strings/"><code>strings</code></a> package adds
    913 an <a href="/pkg/strings/#IndexByte"><code>IndexByte</code></a>
    914 function for consistency with the <a href="/pkg/bytes/"><code>bytes</code></a> package.
    915 </li>
    916 
    917 <li>
    918 The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package
    919 adds a new set of swap functions that atomically exchange the argument with the
    920 value stored in the pointer, returning the old value.
    921 The functions are
    922 <a href="/pkg/sync/atomic/#SwapInt32"><code>SwapInt32</code></a>,
    923 <a href="/pkg/sync/atomic/#SwapInt64"><code>SwapInt64</code></a>,
    924 <a href="/pkg/sync/atomic/#SwapUint32"><code>SwapUint32</code></a>,
    925 <a href="/pkg/sync/atomic/#SwapUint64"><code>SwapUint64</code></a>,
    926 <a href="/pkg/sync/atomic/#SwapUintptr"><code>SwapUintptr</code></a>,
    927 and
    928 <a href="/pkg/sync/atomic/#SwapPointer"><code>SwapPointer</code></a>,
    929 which swaps an <code>unsafe.Pointer</code>.
    930 </li>
    931 
    932 <li>
    933 The <a href="/pkg/syscall/"><code>syscall</code></a> package now implements
    934 <a href="/pkg/syscall/#Sendfile"><code>Sendfile</code></a> for Darwin.
    935 </li>
    936 
    937 <li>
    938 The <a href="/pkg/testing/"><code>testing</code></a> package
    939 now exports the <a href="/pkg/testing/#TB"><code>TB</code></a> interface.
    940 It records the methods in common with the
    941 <a href="/pkg/testing/#T"><code>T</code></a>
    942 and
    943 <a href="/pkg/testing/#B"><code>B</code></a> types,
    944 to make it easier to share code between tests and benchmarks.
    945 Also, the
    946 <a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a>
    947 function now quantizes the return value to an integer (although it
    948 still has type <code>float64</code>), to round off any error caused by
    949 initialization and make the result more repeatable. 
    950 </li>
    951 
    952 <li>
    953 The <a href="/pkg/text/template/"><code>text/template</code></a> package
    954 now automatically dereferences pointer values when evaluating the arguments
    955 to "escape" functions such as "html", to bring the behavior of such functions
    956 in agreement with that of other printing functions such as "printf".
    957 </li>
    958 
    959 <li>
    960 In the <a href="/pkg/time/"><code>time</code></a> package, the
    961 <a href="/pkg/time/#Parse"><code>Parse</code></a> function
    962 and
    963 <a href="/pkg/time/#Time.Format"><code>Format</code></a>
    964 method
    965 now handle time zone offsets with seconds, such as in the historical
    966 date "1871-01-01T05:33:02+00:34:08".
    967 Also, pattern matching in the formats for those routines is stricter: a non-lowercase letter
    968 must now follow the standard words such as "Jan" and "Mon".
    969 </li>
    970 
    971 <li>
    972 The <a href="/pkg/unicode/"><code>unicode</code></a> package
    973 adds <a href="/pkg/unicode/#In"><code>In</code></a>,
    974 a nicer-to-use but equivalent version of the original
    975 <a href="/pkg/unicode/#IsOneOf"><code>IsOneOf</code></a>,
    976 to see whether a character is a member of a Unicode category.
    977 </li>
    978 
    979 </ul>
    980