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><</code></td> 533 </tr> 534 <tr> 535 <td></td><td><code>le</code></td> <td><code><=</code></td> 536 </tr> 537 <tr> 538 <td></td><td><code>gt</code></td> <td><code>></code></td> 539 </tr> 540 <tr> 541 <td></td><td><code>ge</code></td> <td><code>>=</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