Skip to content

docs: clarify numbers.range_step descending range behavior - #85

Open
anakrish wants to merge 2 commits into
mainfrom
fix/numbers-range-step
Open

docs: clarify numbers.range_step descending range behavior#85
anakrish wants to merge 2 commits into
mainfrom
fix/numbers-range-step

Conversation

@anakrish

Copy link
Copy Markdown
Owner

Addresses a PR review comment: the numbers.range_step row in docs/builtins.md had a blank description. OPA v1.19.1 (and our implementation) automatically negates the step when start > stop, producing a descending range. Update the doc row to say so instead of leaving it blank.

anakrish and others added 2 commits August 28, 2026 11:17
Two semantic fixes for numbers.range_step:

1. Non-positive or non-integer step: previously returned an error even
   in non-strict mode; now returns undefined in non-strict mode (matches
   OPA behaviour) and only errors in strict mode.

2. Descending ranges: the previous implementation attempted to compute
   num_elements via i64 arithmetic and bail if it overflowed. This
   failed for large integers because as_i64() returns None for bignums.
   Replace with a direction-aware step: negate the caller-supplied
   positive step when v1 > v2 so the loop walks downward naturally,
   removing the overflow-prone element-count pre-computation.

- Rework the step guard to check non-integer/non-positive first and
  short-circuit with undefined when not strict
- Compute step = incr or -incr based on v1 <= v2 comparison
- Use Vec::new() instead of with_capacity (element count no longer
  pre-computed, still bounded by enforce_limit)
- Add YAML regression test: ascending, step-2, descending, single-
  element, non-integer-step-undefined, zero-step-undefined

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
OPA v1.19.1 automatically negates the step when start > stop to produce a
descending range. Our implementation matches this. Update builtins.md to
document it rather than leaving the description blank.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Changes recommended

The feature column is overwritten, RVM coverage is missing, and the runtime changes are not disclosed in the PR description.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Clarifies numbers.range_step descending behavior and updates its implementation and tests.

Changes:

  • Documents automatic step negation for descending ranges.
  • Refactors range generation and invalid-step handling.
  • Adds interpreter coverage for common and invalid inputs.
File summaries
File Description
docs/builtins.md Documents descending-range behavior.
src/builtins/numbers.rs Revises validation and range generation.
tests/interpreter/cases/builtins/numbers/range_step.yaml Adds interpreter test cases.
Review details
  • Files reviewed: 3/3 changed files
  • Comments generated: 3
  • Review effort level: Balanced

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread docs/builtins.md
| [x * y](https://www.openpolicyagent.org/docs/latest/policy-reference/#builtin-numbers-mul) | _ |
| [numbers.range](https://www.openpolicyagent.org/docs/latest/policy-reference/#builtin-numbers-numbersrange) | _ |
| [numbers.range_step](https://www.openpolicyagent.org/docs/latest/policy-reference/#builtin-numbers-numbersrange_step) | _ |
| [numbers.range_step](https://www.openpolicyagent.org/docs/latest/policy-reference/#builtin-numbers-numbersrange_step) | Supported. When `start > stop`, step is negated automatically to produce a descending range, matching OPA behavior. |
Comment on lines +23 to +30
- note: descending
data: {}
modules:
- |
package test
x = numbers.range_step(5, 1, 1)
query: data.test.x
want_result: [5, 4, 3, 2, 1]
Comment thread src/builtins/numbers.rs
Comment on lines +143 to +147
if !incr.is_integer() || incr <= Number::from(0u64) {
if strict {
bail!(params[2].span().error("step must be a positive integer"))
}
return Ok(Value::Undefined);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants