Have you seen https://golang.org/doc/faq#x_in_std?

Thank you comment and pointer @mvdan. I really appreciate the logic behind Go, and am perfectly fine with these suggestions being rejected. I'd like to read the reasons why or why not, and if not for anything else but to see where people are coming from and the logic. I value the thought experiment greatly!

Rsh and Lsh are very common in crypto, and given they may not be a trivial thing to code by hand-- I'm all for making this something that anyone could use with ease. :)

All the best!

If this is for crypto, is there a reason why you are using []byte instead of big.Int? That type already provides shift operations.

@randall77 good point. I was working the,
crypto/ecdsa: hashToBytes optimization,
and was surprised to find there was no in-place function call to shift bytes in a slice. The Big.Int Set() works well, but the TODO asked to not call Big.Int

Hope this helps explain the logic.

All the best!

This could be reduced down to a single func Shift(data []byte, bits int) function which can accept positive and negative values.

Change https://golang.org/cl/282052 mentions this issue: bytes: Left and right bit shifter for byte slices

@icholy Thank you for the comment. I really appreciate your input here and I fully understand and am sure I have exploited this type of logic before to simplify code.

The biggest question that plagues me here is this: which direction should be positive? I ask this as cartesian coordinates imply that the right is positive, however, when dealing with big-endian numbers the left is positive.

I'd assume negative would be left and positive would be right.

In math/bits, we chose left=positive. We should probably do the same here. https://golang.org/pkg/math/bits/#RotateLeft
(But this proposal seems unlikely to make the cut, see @mvdan 's comment.)

This is something that I've needed to re-implement more than once when parsing annoying (not byte aligned) binary formats. It's tricky to get right, and I think it would be a great addition to the encoding/binary package.

edit: here's an example implementation:

// ShiftLeft performs a left bit shift operation on the provided bytes.
// If the bits count is negative, a right bit shift is performed.
func ShiftLeft(data []byte, bits int) {
	n := len(data)
	if bits < 0 {
		bits = -bits
		for i := n - 1; i > 0; i-- {
			data[i] = data[i]>>bits | data[i-1]<<(8-bits)
		}
		data[0] >>= bits
	} else {
		for i := 0; i < n-1; i++ {
			data[i] = data[i]<<bits | data[i+1]>>(8-bits)
		}
		data[n-1] <<= bits
	}
}

It's large/finicky enough that I don't want to rewrite it in each project, but it's not big enough to live in its own module either.

PR has been updated with both suggestions.

I completely understand, @icholy your frustrations of having to re-implement it each time. I thought, "maybe others would also value this," so I greatly appreciate your agreement here. I found this utility is missing when working on some crypto/encoding libraries.

Yes, and thank you for that valuable shout-out, @randall77. I agree that staying consistent is very important for lowering the learning curve for new and experienced developers.

This is something that I've needed to re-implement more than once when parsing annoying (not byte aligned) binary formats. It's tricky to get right, and I think it would be a great addition to the encoding/binary package.

edit: here's an example implementation:

// ShiftLeft performs a left bit shift operation on the provided bytes.
// If the bits count is negative, a right bit shift is performed.
func ShiftLeft(data []byte, bits int) {
	n := len(data)
	if bits < 0 {
		bits = -bits
		for i := n - 1; i > 0; i-- {
			data[i] = data[i]>>bits | data[i-1]<<(8-bits)
		}
		data[0] >>= bits
	} else {
		for i := 0; i < n-1; i++ {
			data[i] = data[i]<<bits | data[i+1]>>(8-bits)
		}
		data[n-1] <<= bits
	}
}

It's large/finicky enough that I don't want to rewrite it in each project, but it's not big enough to live in its own module either.

This implementation does exactly what you suggest, though it grabs the value from the array to a variable and encourages the compiler to hold it in a register, so as to avoid pulling from memory twice.

This function is inappropriate for package bytes, which is primarily about text, not math on uint8 values.
It is also almost certainly too special for the Go standard library.
But it looks like you have an implementation you are happy with.
I encourage publishing it as a package that others can use.

@rsc : Thank you for your valuable feedback, and yes it is something that I am proud of. On this subject, and before I take any more of your valuable time, would this be something to consider in any other go package (like for example the suggested encoding/binary)?

Unfortunately, the combined function is too complex to be inlined (in 1.16) https://pkg.go.dev/github.com/icholy/bitshift

@icholy please excuse my ignorance, I don't follow what you mean by too complex to be in-lined fully. What I think you are saying is that there are many lines of code. The link to your repo is very much the same thing, but here I was hoping to add the ability to handle shifts greater than 8, even up to 8*len(src). What do you think, crazy?

Each function has a complexity budget of 80 units, use go build -gcflags=-m=2 to see what the compiler things of each function

@pschou https://www.ibm.com/support/pages/what-does-it-mean-inline-function-and-how-does-it-affect-program

@pschou Ive never needed to shift more than 8 bits. I wanted to add a panic if bits was greater than 8, but that also prevents inlining.

@davecheney Thank you for the heads up on this and even more the ability the budget check! I very much appreciate and respect this limit.

@icholy Your implementation is really nice! I very much appreciate it and I wonder if one could squeeze in an & operator, at the top to limit / mod the bits down to 0-7 along with allow alternate src and dst, aka *in and *out...

This function seems inappropriate for the standard library generally.
It is not (apparently) something people need frequently, nor is it
something where the compiler can cut it down to a single instruction
(like most things in math/bits).

This function seems inappropriate for the standard library generally.
It is not (apparently) something people need frequently, nor is it
something where the compiler can cut it down to a single instruction
(like most things in math/bits).

Thank you for the reply. This makes perfect sense and I appreciate your insight and oversight in this matter. Feel free to close this request as desired.

All the best!

No change in consensus, so declined.
— rsc for the proposal review group