Go 1.17 moves to beta, with language and compiler enhancements
Go (golang) 1.17, the next release of the open source, Google-developed programming language, is now in a beta release stage, with changes intended to simplify coding for safety.The first beta was published on June 10, with the production release expected in August. Release notes cite three small enhancements to the language, intended to simplify writing code that conforms to unsafe.Pointer’s safety rules. These enhancements include:An expression s of type []T may now be converted to array pointer type *[N]T. If a is the result of such a conversion, then corresponding indices that are in range refer to the same underlying elements: &a[i] == &s[i] for 0
Go (golang) 1.17, the next release of the open source, Google-developed programming language, is now in a beta release stage, with changes intended to simplify coding for safety.
The first beta was published on June 10, with the production release expected in August. Release notes cite three small enhancements to the language, intended to simplify writing code that conforms to unsafe.Pointer
’s safety rules. These enhancements include:
- An expression
s
of type[]T
may now be converted to array pointer type*[N]T
. Ifa
is the result of such a conversion, then corresponding indices that are in range refer to the same underlying elements:&a[i] == &s[i] for 0 <= i < N
. The conversion panicsif len(s)
is less thanN
. unsafe.Add: unsafe.Add(ptr, len)
addslen
toptr
and returns the updated pointerunsafe.Pointer(uintptr(ptr) + uintptr(len))
.unsafe.Slice
: For expression ptr of type*T, unsafe.Slice(ptr, len)
returns a slice of type[]T
whose underlying array starts atptr
and whose length and capacity arelen
.
For the compiler, Go 1.17 implements a new way of passing function arguments and results using registers rather than the stack. This is enabled for Linux, MacOS, and Windows on the 64-bit x86 architecture. Benchmarking has shown a resulting performance improvement of about 5% and a typical reduction in binary size of about 2%. This change does not affect the functionality of safe Go code but can affect code outside the compatibility guidelines with minimal impacts. Also with the compiler, functions containing closures can be inlined. One effect of this is that a function with a closure may produce a distinct closure function for each place that the function is inlined. This change could reveal bugs where Go functions are incorrectly compared by pointer value. Go functions by definition are not comparable.