std.collection - changing the collection while iterating

[Joseph Cassman via Digitalmars-d]

On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu 
wrote:
> While I work on making std.allocator better, here's some food 
> for thought regarding std.collection.
>
> Consider a traditional container with reference semantics, 
> Java-style. Regarding changing the collection (e.g. 
> adding/removing elements) while iterating, we have the 
> following possibilities:
>
> 1. Leave it undefined, like the STL does. Probably this is too 
> extreme.
>
> 2. Throw an exception if a remove is attempted while ranges 
> exist. This works but it's conservative - e.g. it throws even 
> if those ranges are never to be used again etc.
>
> 3. Allow the removal but throw from the ranges if there's any 
> attempt to use a range following a remove.
>
> 4. Make it work such that ranges continue to be valid post 
> removal. Perhaps this is on the inefficient side.
>
>
> Andrei

I was trying to understand how it could work with array slices. 
For example, I was thinking of code similar to the following from 
TDPL p. 103:

import std.conv, std.stdio;
int main(string[] args) {
   args = args[1 .. $];
   while (args.length >= 2) {
     if (to!int(args[0]) != to!int(args[$ - 1])) {
       writeln("not palindrome");
       return 1;
     }
     args = args[1 .. $ - 1];
   }
   writeln("palindrome");
   return 0;
}

Is the slice above considered a range? If so then it seems that 
(4) is already used a lot in existing D code. If it is not, then 
will slices of the possible future library implementation of 
arrays be considered ranges?

I cannot see all difficulties arising from allowing (4), but I 
imagine code complexity will increase as a result. Perhaps the 
compiler can special case arrays to avoid possible issues making 
(4) allowable for all containers?

Joseph