Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: hash: make the Sum method less confusing #21070
The Go 1
// Sum appends the current hash to b and returns the resulting slice. // It does not change the underlying hash state. Sum(b byte) byte
Individual packages (such as
// Sum returns the MD5 checksum of the data. func Sum(data byte) [Size]byte
I can see two possible improvements.
// AppendSum appends the current hash to b and returns the resulting slice. // It does not change the underlying hash state. AppendSum(b byte) byte
// Sum returns a new slice containing the current hash. // It does not change the underlying hash state. Sum() byte
I recommend option (1), because I think it would migrate more smoothly in binaries that mix Go 1 and Go 2.
I don't see that happening anytime soon. I think
changed the title
proposal (Go 2): hash: make the Sum method less confusing
Feb 27, 2018
This may not be worth the pain. We'd need to make a new v2 hash package, and then either make v2s of all implementations, or add an additional
Why does the method need to be called AppendSum? What other Append operations could it possibly be referring to? If have an Appender interface type with the signature
The original name
@bradfitz Because of the "pain" you mention, I believe if this might ever be done, "Go2" is the only point where it could be. Please don't casually dismiss it too easily. Please note there's also a huge pain in the current state of events. Because of this very issue, I personally have a huge yellow virtual "WARNING" sign attached to the whole hash package in my mind, with the small print saying: "never touch the hash package without cautiously reading the godoc; there's some well-known minefield somewhere there". And I'm certainly not a noob to Go, being in the community since the 2009. Notably, I do also believe that the current shape of the interface can be unnecessarily risky with regards to use in security-related applications (there's a reason why many Hash implementations are located in the crypto package), and in this domain I believe it's generally better to be safe than sorry, including in API design. For the sake of making the virtual world somewhat safer.
I understand this may not be a "prime time" candidate for the "Go2" process. But once some of the necessary Go2 refactoring approaches/mechanisms get tested and proven on some more "attractive" packages/issues, and people get used to them in the Go 2 transition period, I don't see why the "smaller papercuts" issues like this one cannot get pulled onto the bandwagon as well.