Using user-defined types with ranges (that is, the .. .. operator as in for x in y .. step .. z do and the like) are required to have comparison and equality constraints. While the definition of (.. ..) has these constraints on the counter type, and it has and default ^Step : ^T, the compiler does not infer from this that this requires the ^Step parameter to have the same constraints.
This should be caught by the compiler as a discrepancy between the *.fsi file and the implementation file.
Without using the constraints on your type, code would compile, but always fail at runtime. See linked issue for details.
Fixes #6238
Checklist
[x] Test cases added (note: there seem to be ZERO cases for user defined types)
[ ] TODO: a few more test cases and ideally a compile-time test case
[ ] TODO: fix new test case that's now (deliberately) failing
Description
Using user-defined types with ranges (that is, the
.. ..
operator as infor x in y .. step .. z do
and the like) are required to havecomparison
andequality
constraints. While the definition of(.. ..)
has these constraints on the counter type, and it hasand default ^Step : ^T
, the compiler does not infer from this that this requires the^Step
parameter to have the same constraints.This should be caught by the compiler as a discrepancy between the
*.fsi
file and the implementation file.Without using the constraints on your type, code would compile, but always fail at runtime. See linked issue for details.
Fixes #6238
Checklist