So I’ve been doing some coding challenges on HackerRank, and have come to the realization that the standard library sort package doesn’t directly support int32 and int64 slices. It’s trivial to write the interface that allows them to be used since there is an IntSlice type, but it does seem like sort package native types for int32 and int64 should be a thing. Anyone else have thoughts on this? Am I missing something here?
From just a personal point of view … I use []int all the time. The only time []int32 etc comes up is in protobuf generated code or the like, where the size is tied to the wire format. So I expect that the sort package optimized for the common / low hanging fruit cases.
2 Likes
I normally wouldn’t notice much either if I hadn’t been doing these challenges that are sometimes dealing with larger numbers, or have a requirement to have the function return one of the aforementioned types. I’ve just been copy pasting the IntSlice type definition and customizing it to be whichever type I need. Didn’t know if I might be taking the wrong approach there.
Today I’d probably go with sort.Slice, but I guess the specific IntSlice implementations might be faster.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.