maps cannot contain multiple NaN's

[thehowl]

This is behaviour that also surprised me about Go that I did not know about, but apparently, because NaN != NaN, then you can have multiple NaN's as keys in a single map.

In Gno, this leads to a panic due to having duplicate keys.

package main

import (
	"fmt"
	"math"
)

var NaN = math.NaN()

func main() {
	fmt.Println(map[float64]int{NaN: 1, NaN: 2})
}

[petar-dambovaliev]

I think this is actually good. This NaN business can bring trouble with our implementation of the map.
As your example suggests this value type doesn't have well defined ordering.
Unless someone presents a usecase for this i think we should leave it as is.
Off the top of my head i can't imagine this functionality being useful in a Gno context.

[thehowl]

@mvertes What do you think we should do here?

On the one hand, I agree with Petar that this seems a bit of a pitfall - if you do a floating point operation which results in a NaN using user input, it could be a pitfall developers often fall into. There is also corollary here that if a struct contains a float and that float is NaN, then that struct isn't != itself even in the map.

However, it creates an inconsistency with Go and the general assertion that if a == b then m[a] == m[b], because in this case a != b but m[a] == m[b].

[odeke-em]

Yeah the inconsistency of panicking in Gno vs fresh entry in Go IMHO shouldn't be allowed especially in a runtime panic because that kind of deviation would break the powerful promise that Go users inherently draw from and expect: "The Go1 compatibility promise" https://go.dev/doc/go1compat for which programs won't break and will continue to compile and work. It is a very powerful promise that a variety of enterprises and Go adopters have relied on.

Gno saying that we accept Go programs with minimal disruption means that to inherit and onboard all those users, we'd have to be more consistent to that promise too, or at least provide better rationale for a differing behaviour of maps.

[mvertes]

By definition, a comparison of NaN to anything, including itself, will return false. Therefore it should not be used as a key in a map, as it can never be found. This creates also strange effects with iterating, as values indexed by Nan can't be ever retrieved.

I kind of like the black hole singularity aspect of that, but in effect, in the best case, this is an easy way to leak memory (just index it by 'NaN'). Panicking on it seems the least insane solution.

[thehowl]

From a meeting we agreed to bring this in line with the Go behaviour, so we'll need to make sure a map can contain multiple NaN's ahead of the mainnet launch

[mvertes]

See also related issue golang/go#20660

As Russ Cox said somewhere in the discussion, there are only bad answers to that problem. The energy to move from one bad answer (the current state of the Go language) to another is not worth the effort. In our case, even achieving the same bad state as Go is challenging.