[minor] regression: `Foo[0.0] is Foo[-0.0]` is now false

[timotheecour]

regression introduced in bcccb74#comments and 28a755d (2 places in code)

Example

block:
  proc fun(a: static float) =
    static: echo a
  fun(0.0)
  fun(-0.0)
  type Foo[T: static[float]] = object
  doAssert Foo[0.0] is Foo[-0.0]

Current Output

0.0
-0.0
`Foo[0.0] is Foo[-0.0]`  [AssertionError]

Expected Output

0.0

Possible Solution

• cast[uint64](a.floatVal) == cast[uint64](b.floatVal) needs to be more careful to take care of FP denormalization (only 0.0 and -0.0 are special)

Additional Information

• see bcccb74#commitcomment-37990142

[krux02]

Well, the question should be: is it even sane to support floating point numbers as static arguments in types? For example C++ does not allow this.

Alternatively, if this behavior is desired, it should be documented and this issue can be closed.

@timotheecour Really don't used static float type parameters.

[timotheecour]

it was a simple fix (see PR), there's no reason to document odd behavior. C++ templates have many more limitations, this shouldn't be a criterion.
(and yes, nim generics also have some limitations compared to C++ templates but none that can't be worked around with other means)

@timotheecour Really don't used static float type parameters.

this would be breaking change, and prevent using static[Foo] where Foo itself has some float param. static[T] is very useful, enabling things that would otherwise be impossible or less efficient; no need to add arbitrary limitations.

[krux02]

There is still odd behavior left to document. For example let nan1 and nan2 both be constants of NaN. Then Foo[nan1] is Foo[nan2] could be true or false, depending on the payload of nan1 and nan2, because of the binary comparisons. But an exception is made for 0.0 and -0.0 wich are not binary equal.

[timotheecour]

sure, feel free to add a followup PR to document this; I think current behavior is the most sensible given conflicting goals of FP semantics and the need for generic caching.

hmm, how about this case:

type Mod7 = distinct int
proc `==`*(a, b: Mod7): bool = a.int mod 7 == b.int mod 7
type Foo[T: static Mod7] = object
doAssert 0.Mod7 == 7.Mod7
doAssert Foo[0.Mod7] is Foo[7.Mod7] # fails

the question here is whether type equality depend on user defined == for distinct types; I could see arguments going both ways.

eg, if you have:

import mod7_types except `==` # or `import mod7_types` if it's private
doAssert Foo[0.Mod7] is Foo[7.Mod7] # suceeds or fails depending on whether `==` is imported ?

[krux02]

given conflicting goals

That is the point that I want to make. The goals are conflicting. There will be people pushing in one direction and people pushing in the other direction. The solution that I propose: deprecate floating point values in generic type arguments, because I don't think it is a solvable issue, nor do I think that floating point type arguments are particularly useful. Simply: do not fight this battle.