Currently, the Go spec requires that cap(make([]T, n)) == n and cap(make([]T, m, n)) == n. I propose relaxing this constraint from == to >=.
Rationale: the Go runtime already pads allocations up to the next malloc bucket size. By treating the user supplied capacity argument as a lower bound rather than exact bound, there's a possibility to make use of this padding space.
Also, if users really need an exact capacity (which seems like it would be very rare), they can write make([]T, n)[:n:n] or make([]T, m, n)[:m:n].
(See also discussion in #24163.)
Currently, the Go spec requires that
cap(make([]T, n)) == nandcap(make([]T, m, n)) == n. I propose relaxing this constraint from==to>=.Rationale: the Go runtime already pads allocations up to the next malloc bucket size. By treating the user supplied capacity argument as a lower bound rather than exact bound, there's a possibility to make use of this padding space.
Also, if users really need an exact capacity (which seems like it would be very rare), they can write
make([]T, n)[:n:n]ormake([]T, m, n)[:m:n].(See also discussion in #24163.)