Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions Sources/AST/DecimalExtensions.swift
Original file line number Diff line number Diff line change
Expand Up @@ -74,4 +74,27 @@ extension Decimal {
guard self >= Self.int64Min && self <= Self.int64Max else { return nil }
return Int64(truncating: self as NSNumber)
}

/// Whether this Decimal represents a whole number (no fractional part), regardless of
/// magnitude. Unlike ``safeInt64Value`` this does not require the value to fit in `Int64`,
/// so very large integers such as `99999999999999999999` still report `true`.
public var isWholeNumber: Bool {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we cover this in Tests/ASTTests/DecimalExtensionsTests.swift

@philipaconrad philipaconrad Jun 24, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could add some test for that. 馃 I'll work that into my next round of changes for the PR.

guard !self.isNaN && self.isFinite else { return false }

// exponent >= 0 means the value is already a whole number (significand * 10^exp).
guard exponent < 0 else { return true }

#if canImport(ObjectiveC)
// Compaction strips trailing zeros from the significand. If the exponent is still
// negative afterwards, the value is fractional.
var copy = self
NSDecimalCompact(&copy)
return copy.exponent >= 0
#else
var rounded = Decimal()
var copy = self
NSDecimalRound(&rounded, &copy, 0, .plain)
return rounded == self
#endif
}
}
21 changes: 21 additions & 0 deletions Sources/AST/RegoNumber.swift
Original file line number Diff line number Diff line change
Expand Up @@ -133,6 +133,27 @@ public struct RegoNumber: Sendable, Hashable {
}
}

/// Whether this number is a whole number (no fractional part), regardless of magnitude.
/// Unlike ``int64Value`` this returns true even when the value is too large for `Int64`.
public var isInteger: Bool {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a series of tests that verify integerValue in Tests/ASTTests/RegoValueTests.swift. I would suggest adding unit tests there to cover isInteger and isPositive there

switch storage {
case .int(_):
return true
case .decimal(let v):
return v.isWholeNumber
}
}

/// Whether this number is strictly greater than zero.
public var isPositive: Bool {
switch storage {
case .int(let v):
return v > 0
case .decimal(let v):
return v > 0
}
}

}

// MARK: - CustomStringConvertible & CustomDebugStringConvertible
Expand Down
49 changes: 44 additions & 5 deletions Sources/Rego/Builtins/Numbers.swift
Original file line number Diff line number Diff line change
Expand Up @@ -41,24 +41,39 @@ extension BuiltinFuncs {

var step: Int64 = 1
if withStep {
guard case .number(_) = args[2] else {
guard case .number(let stepNum) = args[2] else {
throw BuiltinError.argumentTypeMismatch(arg: "step", got: args[2].typeName, want: "number")
}
// NOTE that we are okay with this argument being a float with integer value
// We are okay with this argument being a float with integer value, e.g.
// numbers.range_step(1.0, 3.0, 1.0) works just fine
guard let stepValue = args[2].integerValue else {
//
// Validate number is a positive whole number directly (not via int64Value), so that
// a whole-number step too large for Int64 is still accepted rather than being
// mistaken for a fractional value.
guard stepNum.isInteger else {
throw BuiltinError.evalError(msg: "step must be integer number but got floating-point number")
}

guard stepValue > 0 else {
guard stepNum.isPositive else {
throw BuiltinError.evalError(msg: "step must be a positive integer")
}

guard let stepValue = stepNum.int64Value else {
// The step is a positive integer too large for an Int64. The span between two
// Int64 endpoints is below 2*Int64.max, so at most only a few elements fall in
// the range. A step just above Int64.max can still be smaller than that span,
// so we use a Decimal for the step size.
return rangeWithDecimalStep(intA: intA, intB: intB, step: stepNum.decimalValue)
}

step = stepValue
}

var result: [RegoValue] = []
return rangeWithInt64Step(intA: intA, intB: intB, step: step)
}

private static func rangeWithInt64Step(intA: Int64, intB: Int64, step: Int64) -> RegoValue {
var result: [RegoValue] = []
if intB > intA {
result.reserveCapacity(Int((intB - intA) / step) + 1)

Expand All @@ -76,7 +91,31 @@ extension BuiltinFuncs {
current -= step
}
}
return .array(result)
}

/// Handle `numbers.range_step` when the step is a positive whole number too large for Int64.
/// The endpoints still fit in Int64, so the span `|b - a|` is below 2路Int64.max and the
/// result holds at most a handful of elements. We iterate in Decimal space (arbitrary
/// precision) to avoid Int64 overflow while remaining correct for steps that are only
/// slightly larger than Int64.max.
private static func rangeWithDecimalStep(intA: Int64, intB: Int64, step: Decimal) -> RegoValue {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we extend rangeStepTests in Tests/RegoTests/BuiltinTests/NumbersTests.swift with validations for of these big steps or do you think compliance tests are sufficient?

let a = Decimal(intA)
let b = Decimal(intB)

var result: [RegoValue] = []
var current = a
if b >= a {
while current <= b {
result.append(.number(RegoNumber(current)))
current += step
}
} else {
while current >= b {
result.append(.number(RegoNumber(current)))
current -= step
}
}
return .array(result)
}

Expand Down
Loading