Proposal Details
See https://go-review.googlesource.com/c/go/+/586616 for example. There's nothing wrong with the change in itself, but there is no guidance about whether it should happen. It's a code rewrite with no semantic effect. It's also a reasonable thing to do, but there are surely many places throughout std that could have a similar change applied. That in turn could lead to many tiny CLs coming in, creating an undue load on maintainers and the trybots to check them.
It's reasonable to suggest that new significant packages, such as "slices", be used in std to show how best to use them. The standard library acts as an exemplar of good Go style.
So I propose two things:
- A policy concisely (if imperfectly) defining when a new package, function, or language feature be deployed throughout std.
- A decision that when such a possibility arises, it be done wholesale, in one or maybe a handful of big CLs, to get it done quickly and efficiently.
Proposal Details
See https://go-review.googlesource.com/c/go/+/586616 for example. There's nothing wrong with the change in itself, but there is no guidance about whether it should happen. It's a code rewrite with no semantic effect. It's also a reasonable thing to do, but there are surely many places throughout std that could have a similar change applied. That in turn could lead to many tiny CLs coming in, creating an undue load on maintainers and the trybots to check them.
It's reasonable to suggest that new significant packages, such as "slices", be used in std to show how best to use them. The standard library acts as an exemplar of good Go style.
So I propose two things: