Argumnentation against external function operator overloading is unconvincing

[Jonathan M Davis via Digitalmars-d]

On Sunday, September 25, 2016 15:45:01 Andrei Alexandrescu via Digitalmars-d 
wrote:
> Ranges don't need necessarily an associated Iterable. This is the case
> in other languages, too; Lisp/Scheme/Haskell/etc lists are iterables and
> at the same time their own iterators. But indeed std.container is
> designed to have containers distinct from their associated ranges, which
> raises the interesting question what should happen if a range gets
> "orphaned", i.e. it's still active after its container ceases to exist.

Another thing to consider here is that given how most range-based functions
will create a new range from the container's range when you pass it to them,
when operating on ranges over containers, you _very_ quickly end up with
ranges that really have nothing to do with the container anymore (hence the
fun problems with removing elements from a container by passing a range to
it). And that highlights how ranges really don't act like they're backed by
containers.

But the safety issue that comes with ranges over containers where the
container goes away is definitely a thorny one - as is the fact that
removing elements from the container while you have active ranges that refer
to it can do funny things to those ranges. I tend to favor C++'s approach to
iterators and how they stay valid, but with D's focus on safety, I don't
know that that's acceptable (though enforcing safety tends to result in
additional overhead which isn't in line with the efficiency goals that go
with being a system language). So, I don't know what the best approach is.

- Jonathan M Davis