On Wed, Jul 8, 2020 at 10:50 AM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote:
> i understand, but think that since Go particularly allows these > conversations transparently, consistency should be covered by language > specification. it potentially causes bugs that doesn't fail fast, didn't > for me anyway. > The spec is silent on this point: https://golang.org/ref/spec#Conversions. Which makes sense since we do not want to pay the cost of the additional logic for consistently handling NaN every time a float is converted to an int since almost none of those conversions will involve NaN. > how much code out there would break if you changed the existing returned > value on x86? > Zero, or so close to it that it doesn't matter. Any code that is depending on int64(float64(NaN)) to result in a particular value is already broken since the language spec doesn't mandate any particular value and the behavior is therefore likely to depend on the compiler version, CPU architecture, and phase of the moon. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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/CABx2%3DD9P%3DAKmj0m2kbR6bzRbq%3DchBQarPAwKEZC%2BqBiWhDoqgg%40mail.gmail.com.
