Ne(int) bad; Ne(uint) good

[omz13]

In bolthold, I used the following construction a few times to loop through all the records in the database :

_ = cfg.badger.ForEach(bh.Where(bh.Key).Ne(0), func(got *Whatever) error {
        got.Whatever()
        return nil
    })

Now, when I moved this over to badgerhold, it no longer worked (as in: no errors thrown and no records retrieved). The solution I discovered was that .Ne(0) needed to be replaced with .Ne(uint(0))... so it seems that badgerhold, unlike bolthold, is a tad sensitive to int/uint?

[timshannon]

Hm. I would expect both to not allow matching directly between unit and int, because Go doesn't. It should use the same level of comparison that Go does. I'll look into it.

[timshannon]

What is the type of Whatever.Key in your example above? int or uint?

[omz13]

a uint64

[timshannon]

So that is expected behavior per the documentation (https://github.com/timshannon/badgerhold#comparing). I tried the same scenario in bolthold, and the behavior is the same as expected.

[omz13]

Ah, mystery solved... but weird... I always thought when comparing with zero it was a case where no explicit casting was needed (since, zero is zero regardless of whether int or unit).

[timshannon]

At compile time, that's true. Go can make assumptions and infer the type. At runtime that is not the case.