For some reason I think this is actually implementation-define behavior, but I'll have a look at the spec real quick. Will CC people in if I can't figure it out.

Yes, this appears to be working-as-intended.

From https://golang.org/ref/spec#Conversions:

In all non-constant conversions involving floating-point or complex values, if the result type cannot represent the value the conversion succeeds but the result value is implementation-dependent.

That's what specified now. If you think it should work differently, please file a proposal issue for it. Closing this one for now.

FWIW #6923 seems somewhat related (I think for constants this sort of conversion may be well-defined), but I don't actually see any proposals. I believe for constants these non-representable conversions are caught at compile-time.

@mknyszek Can you clarify "implementation-dependent" and how to contact the corresponding contributors?

I think it means specifically that Go implementations are free to choose the behavior, which includes allowing these differences across architectures. I suspect this particular rule is chosen as a performance optimization.

In general, the result of such a conversion is fairly non-sensical when you can't represent some value in the new type. By allowing a broad range of behaviors, the compiler is able to generate faster code by not having to deal with the case where the conversion fails. Note that there are lots of places where Go doesn't choose implementation-defined behavior for both platform compatibility and just general programmer sanity, but to me this particular case seems sensible because one frequently can't do anything much with such a conversion.

If you'd like to start a discussion about this, the golang-nuts group is a good place to do so. If you have a specific proposal in mind for how this should work, feel free to file a new issue about it with "proposal:" in the title.