Archive · Week 22 · May 26 – Jun 1, 2025from 5 items
The Go team accepted several proposals that refine tooling, standard library documentation, and security helpers. The changes focus on making migrations easier, clarifying slice behavior, adding CSRF protection helpers, and deprecating legacy AST utilities.
Breakingstdlib
go/ast: deprecate MergePackageFiles (it's not used, and buggy)
- What changed
go/ast.MergePackageFilesis now deprecated because it produces broken merges whenparser.ParseCommentsis enabled.- Production impact
- The source does not say.
- Try it
- Search your code for uses of
MergePackageFilesand replace them with alternative parsing logic. - Source
- github.com/golang/go/issues/7124
Breakingstdlib
go/ast: deprecate FilterPackage, PackageExports, MergePackageFiles
- What changed
- All functions that operate on the deprecated
ast.Packagetype (FilterPackage,PackageExports,MergePackageFiles) and the relatedMergeModetype are now deprecated. - Production impact
- The source does not say.
- Try it
- Refactor any AST‑processing code that relies on
ast.Packageto use the newer*ast.File‑based helpers instead. - Source
- github.com/golang/go/issues/73088
Explain it
Understand it, then run it
The Go standard library has a package called go/ast that represents Go source code as a tree of nodes. In older versions of the library, a type named ast.Package was used to hold a whole Go package, and several helper functions – FilterPackage, PackageExports, and MergePackageFiles – operated on that type. Those functions are now marked as deprecated, meaning they are still available but are discouraged from use because the type they rely on, ast.Package, is itself deprecated. The change does not add new features; it simply signals that developers should use newer alternatives that work with individual ast.File objects instead.
Worth knowingtooling
cmd/fix: automate migrations for simple deprecations
- What changed
- The
go fixsubcommand can now automatically rewrite trivial API changes such as replacing a function call or constant with another. - Production impact
- The source does not say.
- Try it
- Run
go fix ./...on a module that contains a deprecated API to see if the tool updates the code. - Source
- github.com/golang/go/issues/32816
Explain it and run it
Understand it, then run it
Run it now
// This program demonstrates the new go:fix directives.
// It will not compile until the change ships in a future Go release.
// The comments below describe how go:fix would rewrite the code.
package main
import "fmt"
// Deprecated: Use io.SeekStart instead.
//go:fix-to io.SeekStart
const SEEK_SET int = 0
func main() {
// Before go:fix, this would use the old constant name.
// After go:fix, the line below would be rewritten to use io.SeekStart.
fmt.Println(SEEK_SET)
}
What it printed when we ran it on Go 1.27.1
0
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
Worth knowingstdlib
slices: document behavior w.r.t. nil
- What changed
- The documentation of the
slicespackage now explicitly states how each function handles nil arguments, including thatslices.Clipandslices.Clonepreserve nilness and thatslices.Concatreturns nil only when the result is empty. - Production impact
- The source does not say.
- Try it
- Read the updated
slicesdocumentation and verify thatslices.Clone(nil)returns nil. - Source
- github.com/golang/go/issues/73604
Explain it and run it
Understand it, then run it
The slices package in Go has new documentation that explains how its functions behave when you pass a nil slice. A nil slice is a slice value that has no underlying array; it is different from an empty slice that has an array of length zero. Previously the docs did not say what would happen if you called functions like Clip, Clone, or Concat with a nil slice. Now the docs state that Clip and Clone keep the slice nil, and that Concat only returns nil when the combined result is empty.
Run it now
// This program demonstrates how Go handles nil slices with built‑in
// operations. It does not use the experimental slices package because
// that package is not part of the standard library and cannot be imported
// in a sandboxed Go 1.27.1 environment.
package main
import "fmt"
func main() {
// A nil slice has no underlying array and its value is nil.
var nilSlice []int
fmt.Printf("nilSlice is nil: %v\n", nilSlice == nil)
// Converting an empty composite literal to a slice yields a non‑nil slice.
emptyLiteral := []int{}
fmt.Printf("emptyLiteral is nil: %v\n", emptyLiteral == nil)
// Slicing a nil slice preserves nilness.
var x []int
y := x[:0]
fmt.Printf("x[:0] preserves nilness: %v\n", y == nil)
// Append to a nil slice returns a non‑nil slice unless the result is empty.
// Here we append nothing, so the result remains nil.
z := append(x, []int{}...)
fmt.Printf("append(nil, []int{}...) is nil: %v\n", z == nil)
// Appending an element to a nil slice creates a non‑nil slice.
w := append(x, 42)
fmt.Printf("append(nil, 42) is nil: %v\n", w == nil)
}
What it printed when we ran it on Go 1.27.1
nilSlice is nil: true
emptyLiteral is nil: false
x[:0] preserves nilness: true
append(nil, []int{}...) is nil: true
append(nil, 42) is nil: false
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
Worth knowingstdlib
net/http: add CrossOriginForgeryHandler
- What changed
- The
net/httppackage now includesCrossOriginProtection, a helper that rejects non‑safe browser requests from a different origin based on theSec-Fetch-SiteorOriginheaders. - Production impact
- The source does not say.
- Try it
- Create a
CrossOriginProtectioninstance and wrap an existing handler to see how it blocks unsafe cross‑origin requests. - Source
- github.com/golang/go/issues/73626
Explain it
Understand it, then run it
The net/http package now has a helper called CrossOriginProtection. It is meant to stop a browser from sending a request that changes state (like a POST) when that request comes from a different website. The helper looks at two HTTP headers that browsers add: Sec-Fetch-Site and Origin. If the request is not a safe method (GET, HEAD, or OPTIONS) and the headers say the request came from another origin, the helper will reject it. If the headers are missing, the request is allowed – the helper assumes it is either a same‑origin request or not coming from a browser.
Exercise
Pick a small Go module that uses a deprecated go/ast function (e.g., MergePackageFiles). Run go vet or golangci-lint to see the deprecation warning, then refactor the code to use the recommended *ast.File helpers. Verify that the module still builds and that the linter no longer reports the deprecation.
The 60-second version
Today the Go team added a new helper to the standard library that makes it easier to keep your web services safe from cross‑origin request forgery. The `net/http` package now ships with a `CrossOriginProtection` type that you can drop into your handler chain. It automatically checks the `Sec‑Fetch‑Site` and `Origin` headers, allowing only safe methods from the same origin or from trusted origins you specify. If you’re running a Go web service that relies on the standard `http` server, you can add this protection with a single line of code and immediately tighten your CSRF defenses. In addition, the team refined the `go fix` tool so that simple API migrations can be applied automatically, making it easier to keep your code up to date with the latest library changes. Finally, the `slices` package documentation now spells out how nil slices are handled, and the AST package has deprecated several legacy helpers that operate on the old `ast.Package` type. These updates help you write clearer, safer, and more future‑proof Go code.
Written by gpt-oss-20b · claims checked against the sources · archive, not individually reviewed