# [OpenSCAD] RFC: Array/String slicing and half open ranges.

Torsten Paul Torsten.Paul at gmx.de
Sat Nov 9 06:32:47 EST 2019

```On 08.11.19 18:45, Doug Moen wrote:
> On Fri, Nov 8, 2019, at 4:43 AM, gasstationwithoutpumps wrote:
>> Putting in something that looks like the Python slice but has
>> a subtly different semantics is probably a bad idea.
>
> I agree with this.

I don't. It's a very sensible thing to look at what other
languages do and learn from them. But not evolving OpenSCAD
because some other language is different would mean there's
nothing to change anymore, ever.

a different definition of ranges compared to python. That's
a fact that can't be changed.
So we can't just use the python slicing because we don't
really want that inconsistent behavior *inside* the OpenSCAD
language itself.

I'm not convinced that introducing a second range notation
is really the best way to go. If we we decide to do so, we
might want to support it for both ranges and slices anyway
so that decision can be left for later.

Just to point that out again. Slices and Ranges only look
the same. They do *NOT* behave the same!

a = [0, 1, 2, 3, 4];

a[2:1:-2] is a slice that returns the elements 2,3

The range [2:1:-2] is always an empty range

I'll probably drop the half-open definition for now as there
seems to be no good idea yet how to handle it. I do like the
[3:<5] specification, but the discussion on IRC pointed to
an issue that comes up with ranges going backward. If step
is negative, the '<' is at least slightly strange [-5:-1:<-3].
There was the suggestion to use [-5:-1:!-3] to mean "not the
end value" but I'm not sure yet we can actually parse that.

So maybe it's better to just decouple both topics.

On 04.11.19 19:12, Jordan Brown wrote:
> BTW, would [>2:5] yield 3,4,5?
> Would these < and > modifiers work on ranges too?

No, so far I have never seen the need to have ranges open
at the beginning. The half-open declaration should work for
both slices and ranges, if we find a way how to express that.

On 05.11.19 22:37, Parkinbot wrote:
> echo(skip_last = a[:\$end-1]);
> // ECHO: skip_last = [0, 1, 2, 3, 4, 5, 6, 7, 8]

I'm not sure that's better. If the argument is that ranges
and slices are different, that does not change with using
\$end.
It does have the benefit of being more verbose and explicit
but \$end does not have any meaning for ranges. So we are
back to having different behavior. The only way to have
same behavior always would be to drop the "count from end"
notation completely. But I think this is useful enough to
be added, even if it makes ranges and slices different.

ciao,
Torsten.

```