I agree it has no technical merit. It can't do better, but it avoid having to think about the type mismatch. The functionality provided by ByteOrder is fairly simple to begin with, I assume its whole purpose is to reduce cognitive load/avoid dumb mistakes. My assumption is that it's probably not immediately obvious to everyone whether `a := int64(unsigned_value)` never loses precision or never reinterprets/reorders the physical value of the bytes. At least I had to stop and think about it and the benefit of a things like ByteOrder would be not having to think :) Then again, I'm not particularly bright.
On Saturday 27 July 2024 at 22:13:59 UTC+2 wagner riffel wrote: > a2800276 <a280...@gmail.com> wrote: > > Just out of curiosity, does anyone have a good rationale as to why there > > are only unsigned conversions available `binary.ByteOrder`? It would > seem > > that this functionality is there to avoid dumb careless errors doing > byte > > order conversions, but this design forces me to have to think about > whether > > I can cast uint64 to int64 without loss of precision ... > > I don't understand how an Int64() method can do any better than int64(x) > conversion, neither how there's loss of precision if both are the same > size, and > on any computer I'm aware of both types uses the same bit pattern. So maybe > that's the rationale, use regular uint64 -> int64 langauge conversion. > > BR. > > -w > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/469a8e0a-8e1f-42a1-a255-e79459f9573cn%40googlegroups.com.
