# Removing elements from dynamic arrays?

Fredrik Olsson peylow at gmail.com
Wed Nov 1 01:17:17 PST 2006

```Chris Nicholson-Sauls skrev:
<snip>
> # import cashew.utils.array;
> #
> # int[] foo = ... ;
> # foo.remove(3U);
> # foo.removeRange(2U, 7U);
> # foo.removeSub(foo[1 .. 5]);
> etc.
>

I like these.

And I yet again see a situation where range and set types are useful. If
a range, or a set where a basic type (just as an integer, or imaginary
float) then removing a range, or a set of elements would be more
intuitive. And the slice operation would not be an array-hack, but a
more general expression reusable everywhere.

Imagine we have: int foo[] = [1,2,3,4,5,6];
// Each example is now assumed unrelated to all others!
foo.remove(1); // foo == [1, 3, 4, 5, 6]
foo.remove(1..3); // foo = [1, 5, 6];
foo.remove(<1, 4..5>); // foo = [1, 3, 4]

or a "slice" using a set:
auto bar = foo[<1, 4..5>]; // bar == [2, 5, 6]

Naturally this would require a range's upper bound to be inclusive, or
else set's would behave unintuitive. That is todays:
foo[5..5] would be a slice with one element, not empty as is.

Today passing around a range can only be done by passing around two
values, or a struct. The same could be said about passing around
imaginary numbers. Why imaginary numbers are valuable enough to warrant
build in types, while ranges are not is beyond me. I use ranges way more
than imaginary numbers.

Same goes for sets. Sure bitshifted enumerations, and boolean logic does
the same trick. But adding it as a build in type would allow for far
more expressive and intuitive code (Just how would you do a foreach over
some "ored" enumeration constants?)

// Fredrik Olsson

```