On 16 August 2021, the Go team released Go 1.17, which you can get by visiting the download page. This release brings an additional improvement to the compiler in the form of a new way of passing function arguments and results. This change shows an approximate 5% improvement in the performance of Go programs and an approximate 2% reduction in binary file size for the amd64 platform. Future versions will support more platforms.
Go1.17 adds support for Windows/ARM64. A trimmed module graph has been introduced in this release. Modules specified in the go.mod file for Go 1.17 or later have a module graph that contains only direct dependencies on other Go 1.17 modules and not their passed dependencies. This helps to avoid the need to download or read the go.mod file and can save time in day-to-day development.
Go 1.17 release content
Go 1.17 makes three small changes to the language.
- Conversion from a slice to an array pointer. An expression s of type []T can now be converted to an array pointer of type *[N]T . If a is the result of such a conversion, then the corresponding indices in the range refer to the same underlying elements: &a[i] == &s[i] for 0 <= i < N . If len(s) is less than N , the conversion gets bogged down.
- Add(ptr, len) Adds len to ptr and returns the updated pointer unsafe.Pointer(uintptr(ptr) + uintptr(len)).
- Unsafe.Slice: For an expression ptr of type *T, unsafe.Slice(ptr, len) returns a slice of type []T whose underlying array starts at ptr and whose length and capacity are len.
These enhancements have been added to simplify writing code that conforms to the unsafe.Pointer “safety rules”, but these rules remain unchanged. In particular, existing programs that use unsafe.Pointer correctly are still valid, and new programs must still follow these rules when using unsafe.
There are many other improvements and bug fixes, including improvements to crypto/x509 authentication, and changes to URL query parsing. For a full list of changes and more information on these improvements, please see the full release notes.
Progress on the Go generic proposal
Ian Lance Taylor, a core member of the Go team, announced earlier this year that he had submitted a proposal to add generics to Go, and Ian blogged: “The language change to add generics to Go is fully backward compatible, and existing Go programs will continue to work as they do today. "
Draft panacea design brief
- Functions can use a list of type arguments with square brackets, which is otherwise the same as a normal argument list:
func F[T any](p T) { ... } - These type arguments can be used by regular arguments, or in the function body
- Types can also use a list of type parameters:
type M[T any] []T - Each type parameter has a type constraint, just as regular parameters have a type: -
func F[T Constraint](p T) { ... } - Type constraints belong to interface types
- The new pre-declared name any is a type constraint that allows any type
- interface types used as type constraints can use a list of pre-declared types; only type arguments matching one of these types can satisfy the constraint
- A generic function can only use operations allowed by its type constraint
- Using a generic function or type requires passing type parameters
- In the usual case, type inference allows the omission of type parameters for function calls
The Go Team was expecting to add generics to Go 1.17, but we’re sorry to say that it’s been delayed again. In response to the delayed generic proposal, the Go Team also said on their official blog that people are looking forward to generics, so they have been working hard to polish up the details to make them usable, with a focus on 2021. The goal is to have it available to everyone in the Beta of Go1.18 by the end of 2021, so it’s no surprise that the generic will be implemented in Go1.18, so we’ll see.
Reference links.