SY-4127: Divide F64 Typecast - Trade and RFC

[sy-nico]

Pull Request

SY-4127

Greptile Summary

This PR adds an RFC and a trade study documenting the decision to have Arc's / and ** operators always return f64 and to replace divide-by-zero panics with IEEE 754 special values (+Inf, -Inf, NaN). The documents are comprehensive and well-reasoned, covering type-system arguments, precision trade-offs, migration guidance, and a full change-footprint breakdown.

Confidence Score: 5/5

Documentation-only PR; safe to merge with the minor example-clarity nit addressed.

Both files are documentation (RFC + trade study); no production code is changed. The single finding is a P2 style issue in a code example. No logic bugs or security concerns.

docs/tech/rfc/0038-260425-division-power-f64-typecast.md — §3.2 code examples

Important Files Changed

Filename	Overview
docs/tech/rfc/0038-260425-division-power-f64-typecast.md	RFC specifying division/power always return f64, with IEEE 754 divide-by-zero semantics; two identical code examples in §3.2 reduce readability of the key NaN vs +Inf contrast.
docs/tech/rfc/0038-260425-divide-typecast-f64-trade-study.md	Trade study evaluating Option A (f64 output) vs Option B (preserve input type); well-structured with criterion-by-criterion analysis and a clear recommendation for Option A.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Arc expression: a / b  or  a ** b"] --> B{Operator}
    B -->|"/  or  **"| C["Analyzer: force result type → f64"]
    B -->|"+ − × %"| D["Return input type (no change)"]
    C --> E{Execution context}
    E -->|Flow node| F["divide{} / pow{} host function\n(T, T) → f64"]
    E -->|WASM func block| G["Compiler emits call to\nmath.divide / math.pow host fn"]
    F --> H{Denominator = 0?}
    G --> H
    H -->|"n/0, n≠0"| I["+Inf or -Inf (truthy)"]
    H -->|"0/0"| J["NaN (non-truthy)"]
    H -->|normal| L["f64 result"]
    I --> M[isSeriesTruthy check]
    J --> M
    L --> M

Loading

_{Reviews (3): Last reviewed commit: "SY-4127: Update docs based on feedback/d..." | Re-trigger Greptile}

[pjdotson]

I left comments here, but we should be mostly having discussions about this in-person, I just wanted to put extra things to think about. I also think that the error / exception handling is something that needs to be discussed as well: what does returning errors for functions look like in both the flow and func contexts (this is something that also is encountered with ranges + statuses RFC and it really does not feel like we have a consistent story on that, and instead are just doing things slapshot as they arise).

[sy-nico]

@pjdotson , replying to your top-level comment.

• Agreed, but it was time to put the concerns on paper since the discussion was starting to go in circles. I needed your thoughts/concerns/objections in a way that I could address point by point. Something that gets hard to do in-person the longer the conversation drags on.
• Also agreed that error/exception handling needs to be discussed, but not here. Typecasting division to f64 cleanly sidesteps this conversation to the contexts where errors/statuses actually make sense (metadata CRUD, etc.), rather than math operations.
• If we went with Option B, error handling would absolutely need to be part of this RFC. That's another reason Option A is the cleaner choice: it removes the error-handling question from the math layer entirely and lets us tackle it in the contexts where it actually belongs, rather than shoe-horn error handling and create more avenues for inconsistency, which backs us into a corner.

[pjdotson]

I don't see where you are getting these definitions of strongly vs strictly. From what
I've read before about typing in languages, there is a general strong typing vs weak
typing axis, along with static typing vs dynamic typing and nominal vs structual. But I
haven't heard and can't really seem to find a difference between strict and strong

[pjdotson]

See my comment below, but it feels like that the sections: type system consistency,
precision errors, and consistency with other operations are mostly reiterating the same
point. There should be one section called user expectation that goes for option A
because most current users expect it to return a float, and another section for
mathematical operator type consistency that goes with option B because when we perform
these primitive math operators (/, %, +, etc.) that are binary operators on two
objects of the same type, the output is the same type as the inputs.

[pjdotson]

seems to be the same argument as some of the above sections as well

[pjdotson]

should add a section explicitly stating that error / exception behavior would need to be
added here as well for option B.