discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Behavior of "backward" ranges

JB
Jordan Brown
Wed, Mar 19, 2025 4:48 AM

Background:

"Backward" ranges without an explicit increment, where the start is
greater than the end, e.g. [10:0], have long given a deprecation warning:

DEPRECATED: Using ranges of the form [begin:end] with begin value
greater than the end value is deprecated in file ., line 1

and implicitly reversed the begin and end values.  This did not happen
for ranges with explicit increments; a range with the start greater than
the end and an explicit positive increment yielded no results, and vice
versa for a range with a negative increment.

Such an "empty range" is often useful in degenerate cases, e.g.
[0:1:len(v)-1] to step through the indexes of all of the entries in a
vector yields nothing when the vector is empty. 

There is also a warning when a range entirely composed of constant
numbers, with an explicit increment, is "backwards":

WARNING: begin is greater than the end, but step is positive in file
., line 1

The rationale for the warning is that if you compute some part of the
range it can be useful to have an empty range.  However, if all of the
parameters to the range are constants, the range can never yield any
values and is probably an error.

Changes:

With my PR#5750 ranges without an explicit increment are no longer
handled specially.  A range without an explicit increment is treated
exactly the same as a range with an explicit increment of 1, which means
that a "backward" range, where the start is greater than the end, yields
no results.

The warning now applies to all constant "backward" ranges, whether or
not they have an explicit increment.

As always, if you have any questions just ask.

Background: "Backward" ranges without an explicit increment, where the start is greater than the end, e.g. [10:0], have long given a deprecation warning: DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated in file ., line 1 and implicitly reversed the begin and end values.  This did not happen for ranges with explicit increments; a range with the start greater than the end and an explicit positive increment yielded no results, and vice versa for a range with a negative increment. Such an "empty range" is often useful in degenerate cases, e.g. [0:1:len(v)-1] to step through the indexes of all of the entries in a vector yields nothing when the vector is empty.  There is also a warning when a range entirely composed of constant numbers, with an explicit increment, is "backwards": WARNING: begin is greater than the end, but step is positive in file ., line 1 The rationale for the warning is that if you compute some part of the range it can be useful to have an empty range.  However, if all of the parameters to the range are constants, the range can never yield any values and is probably an error. Changes: With my PR#5750 ranges without an explicit increment are no longer handled specially.  A range without an explicit increment is treated exactly the same as a range with an explicit increment of 1, which means that a "backward" range, where the start is greater than the end, yields no results. The warning now applies to all constant "backward" ranges, whether or not they have an explicit increment. As always, if you have any questions just ask.