Thanks, that is a good idea. But we can't make that change now, as it will break the Go 1 compatibility guarantee.

I think a better alternative which elide allocations is to use zero sized dedicated types:

type errInvalid struct{}

func (errInvalid) Error() string {
	return "invalid argument"
}

type errPermission struct{}

func (errPermission) Error() string {
	return "permission denied"
}

type errExist struct{}

func (errExist) Error() string {
	return "file already exists"
}

type errNotExist struct{}

func (errNotExist) Error() string {
	return "file does not exist"
}

type errClosed struct{}

func (errClosed) Error() string {
	return "file already closed"
}

var (
	ErrInvalid    errInvalid
	ErrPermission errPermission
	ErrExist      errExist
	ErrNotExist   errNotExist
	ErrClosed     errClosed
)

It technically is possible to reassign them, os.ErrInvalid = os.ErrInvalid is valid code, however that do absolutely nothing so it's fine and avoid an allocation every time someone return or errors.Is the error value. Nvm passing constant strings as interfaces allocate the string header as a global, I still think something like var ErrInvalid errors.Error[osError, "invalid argument"] is better.

Would be nice to find a less verbose way to express this.
If we could pass const as type parameters could do:

type errInvalid errors.Error["invalid argument"]
var ErrInvalid errInvalid

A helper like this would allow to easily create individual errors which wrap a parent error for wildcard checking:

type Error[Wrapping error, Message const string] struct{}

func (Error[Wrapping, Message]) Error() string {
 return Message
}

func (Error[Wrapping, Message]) Unwrap() error {
 var zero Wrapping
 return zero
}

One drawback of using constant string errors is, we can easily invent new errors of the same type:

package main

type osError string

func (err osError) Error() string {
	return string(err)
}

const ErrInvalid = osError("invalid argument")

func main() {
	var myError error = ErrInvalid + " 2"
	println(myError.Error())
}

Maybe, it is a good idea to add a vet rule: find all modifications of global error values (including the operations taking addresses of global error values).

Would be nice to find a less verbose way to express this. If we could pass const as type parameters could do:

type errInvalid errors.Error["invalid argument"]
var ErrInvalid errInvalid

To add to this, there's already a precedent for const type parameters: Arrays

var (
	a [4]int
	b [3]float32
	c [8]string
)

Without getting too off track, has Go considered adding a val qualifier to ensure the variable can't be re-assigned post initialization ? I'd be interested in reading a thread about it if there is one. I've read through several proposals about adding immutable types and found myself agreeing with the arguments against it, but it seems like preventing re-assignment and leaving interior mutability to the type (i.e no setters) might be middle ground solution that could apply to more than just errors.

@psnilesh There is https://go.dev/issue/21130.