This operation is often called extract, as in the Intel BEXTR instruction or the Rust bextr method (https://docs.rs/bitintr/latest/bitintr/trait.Bextr.html). I think Extract would be a better name than Select.

That said I'm not 100% sold on a function that takes three arguments all of the same type. It seems easy to mix things up. And why are i and n type uint anyhow? Wouldn't it be more typical of Go to make them type int?

I feel like if we're going to include this, we probably want the other direction (Insert) as well?

They both seem pretty simple, not sure they need to be in math/bits. Most of the stuff there constitutes intrinsics that can't be easily written in Go.

Could this be written as a generic function over a constraint including all of the unsigned integer types?

type Bits interface {
    uint | uint8 | uint16 | uint32 | uint64
}

func Extract[B Bits](x B, i, n int) B {
    return (x >> i) & ((1 <<  n) - 1)
}

I see that the functions already in that package are not generic, but I'm not sure if that's just because this package predated generics or if there's an important implementation reason. (I do notice that some of them have tailored implementations for each size, and so could not be trivially generalized.)

FWIW, I do kinda agree that this function isn't clearly needed. I don't think I'd go looking for a function like this in stdlib if I hadn't seen this proposal, because I'm accustomed to having to do this sort of thing directly with arithmetic operators in other languages. It does seem like it would improve readability of code that uses it, though.

There was a proposal for the parallel versions, PDEP & PEXT.

#45455 proposal: math/bits: add Deposit and Extract functions