I love how the conjunction of #golang's modules system and build constraints lets you have your cake and eat it too! 🍰

You can let users of your library take advantage of the bleeding edge if they so wish without cutting off one of the currently supported Go toolchains.

When something tantalising gets merged at tip, you can put code that relies on it in a file guarded by a //go:build go1.27 build constraint and its pre-1.27 counterpart in a file guarded by a //go:build !go1.27 build constraint. No need to update your go.mod's go directive.

Even when you cannot eliminate all bounds checks within a loop, eliminating most of them may benefit performance. 😉
#golang

https://go-review.googlesource.com/c/go/+/759100

Paradoxically (perhaps), as the Go compiler becomes better at eliminating bounds checks, attacker-reachable panics due to incorrect programmer assumptions about indices become easier to find.

#golang

#golang quiz: What happens if you try to compile and run the following program?

package main

import (
"fmt"
"math"
)

func main() {
fmt.Println(int(math.NaN()))
}

🚀 "spec: generic methods for Go" has been accepted!

You will soon (1.27?) be able to declare (on concrete types only) methods that introduce type parameters, i.e. type parameters other than the ones (if any) that come from the method's receiver.

Since the inception of generics in Go (1.18), methods could not introduce type parameters. You had to resort to declaring package-scoped functions instead; code organisation and ergonomics typically suffered.

The proposal lifts this restriction for concrete types (though not for interface types).

https://github.com/golang/go/issues/77273#issuecomment-3962618141

#golang

A friendly reminder that a Go program doesn't need an import of the "unsafe" package to undermine the language's type system; a synchronisation bug may be enough: https://go.dev/play/p/L0_ZrqS2-4a

#golang