Numeric inference in 3.0.0 appears broken

[panesofglass]

In FSharp.Data 3.0.0-beta4, inference for a JSON with a numeric array field worked properly. When attempting to upgrade to 3.0.0, however, the inference breaks, and the inferred type is int []. I'm currently working on a repro test case. This is preventing our ability to update to the 3.0.0 release version.

[panesofglass]

I suspect this commit may be the culprit, but I'm still looking: 8d05e4b

[atlemann]

What does your numeric array field look like? After bumping to v3.0, 0.1e1 is inferred as int. To fix it I had to change to 0.1e0 or 0.11e1.

For arrays, make sure all the entries are in exponential format. Maybe that helps.

[panesofglass]

I'm figuring out ways to work around this, but I think the general inference should be that, if there's an e or E in the string representation, it should be a float.

[baronfel]

I think we could solve this with some additional information attached to the JsonValue.Float case that let us know if the float value was exponential or not. Then we could use that flag to disallow inferring the sample value as an integer at all.

[github-actions]

🤖 This is an automated response from Repo Assist.

This bug is still present in the current codebase. Here's the confirmed root cause:

Root cause — JsonInference.fs lines 52–63 infer a JsonValue.Float as int when its value happens to be a whole number:

| JsonValue.Float f when
    shouldInferNonStringFromValue
    && inRangeFloat Int32.MinValue Int32.MaxValue f
    && isIntegerFloat f   // Math.Round f = f  →  1.0 = true!
    ->
    InferedType.Primitive(typeof(int), None, false, false)

Since 0.1e1 can't be parsed as a .NET Decimal (decimal doesn't support exponent notation), the parser falls through to JsonValue.Float(1.0). Then isIntegerFloat 1.0 = true, so inference promotes the value to int.

Potential fixes (increasing invasiveness):

1. Simplest / cleanest: Remove integer inference for JsonValue.Float entirely — always infer it as float. JSON 1.0 is syntactically a floating-point number; any tool that writes 1.0 intends a float. This is a breaking change for schemas where floats that happen to be whole numbers were previously inferred as int, but is arguably semantically correct.

2. Preserve original source flag: Thread a boolean through JsonValue.Float (e.g. Float of float * wasExponential: bool) indicating the original text contained an e/.. Infer as float unconditionally when wasExponential = true. Requires a parser and AST change; preserves backward compatibility for plain 1.0 literals.

3. Schema override: As a short-term workaround, users can force the field type with the Schema parameter or provide a sample that only contains non-integer floats (e.g. 0.5 instead of 1.0).

Fix (1) is the most defensible long-term solution. Happy to submit a PR if a maintainer endorses it — it would need tests added for 0.1e1 / 1e3 etc. being inferred as float[] rather than int[].

Generated by Repo Assist

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@828ac109efb43990f59475cbfce90ede5546586c. View source at https://github.com/githubnext/agentics/tree/828ac109efb43990f59475cbfce90ede5546586c/workflows/repo-assist.md.

[dsyme]

We want this:

Preserve original source flag: Thread a boolean through JsonValue.Float (e.g. Float of float * wasExponential: bool) indicating the original text contained an e/.. Infer as float unconditionally when wasExponential = true. Requires a parser and AST change; preserves backward compatibility for plain 1.0 literals.

[dsyme]

Actually looking at this I think we don't change this. All the solutions are too invasive