That proposed change would break the spirit of the Go 1 compatibility guarantee, so we're not going to do it. (The Go 1 compatibility guarantee doesn't cover cgo, but, we're still not going to gratuitously break existing code without a really good reason.) And though the issue is marked "Go 2", there isn't going to be a Go 2, and we aren't going to make a cgov2 for something like this.

So I suggest a different proposal:

// GoStringBigN is like GoStringN but for very large strings.
func GoStringBigN(*C.char, C.size_t)

// GoBytesBig is like GoBytes but for very large data.
func GoBytesBig(unsafe.Pointer, C.size_t)

That would be fine with me. Alternatively, perhaps it would be possible to widen the argument types to accept both (e.g., func GoStringN[T C.int | C.size_t](*C.char, T) in generics style).

I think we already provide too many cgo helper functions, and I would prefer that we deprecate them rather than expanding them.

In particular, these functions seem redundant with the recently-added unsafe.String, unsafe.Slice, and bytes.Clone. Consider:

func goStringN(p *C.char, n C.size_t) string {
	return string(unsafe.Slice((*byte)(unsafe.Pointer(p)), n))
}

func goBytes(p unsafe.Pointer, n C.size_t) []byte {
	return bytes.Clone(unsafe.Slice((*byte)(p), n))
}

This proposal has been declined as infeasible.
— rsc for the proposal review group