BUG: 0.0/2.0 exports to int

[rudolph9]

Cue version: 27b9ca3

Internally I believe the representation is correct. However, the export I believe to be wrong given that 0 & float yields an error.

a: 0.0 & float
b: a / 2.0
c: float & b + 1.0

:!cue export bug.cue
{
    "a": 0.0,
    "b": 0,
    "c": 1.0
}

[rudolph9]

{ "a": 0 }
a: float

:!cue eval bug.cue --all --ignore
a: _|_ // conflicting values float and 0 (mismatched types float and int)

[mpvl]

If a type is a float, it should probably include a . somewhere, indeed.

The second example is correct, though. 0 is an int, which is not a float. In general, it is advisable to use number instead of float in apis.

[mpvl]

Note that for export this behavior is likely fine, though, as the output is JSON and not CUE.

[rudolph9]

That makes sense but also a little weird. For example the following:

foo: number
foo: 2.0
foo: 2

foo: conflicting values (number & 2.0) and 2 (mismatched types float and int):
    ./foo.cue:1:6
    ./foo.cue:2:6
    ./foo.cue:3:6

shell returned 1

It seems like maybe [0-9] should have number type and only once unified with float or int would they be considered more constrained but that is weird too since int then wouldn't be a strict subset of number. 🤔

[rudolph9]

@mpvl It looks like there is some interesting behavior when you mix and match floats with ints and export

zeroIntOverOneInt: 0 / 1
zeroFloatOverOneInt: 0.0 / 1
zeroIntOverOneFloat: 0 / 1.0
zeroFloatOverOneFloat: 0.0 / 1.0

:!cue export %
{
    "zeroIntOverOneInt": 0,
    "zeroFloatOverOneInt": 0.0,
    "zeroIntOverOneFloat": 0E+1,
    "zeroFloatOverOneFloat": 0
}

Correct me if I'm mistaken but I think zeroFloatOverOneInt and zeroFloatOverOneFloat is a bug (or at least d06f2d4 introduced an inconsistency)

I'm not sure what to think about the behavior of zeroIntOverOneFloat but it's probably fine.

[cueckoo]

This issue has been migrated to cue-lang/cue#233.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.