Argumnentation against external function operator overloading is unconvincing

[pineapple via Digitalmars-d]

On Sunday, 25 September 2016 at 13:45:01 UTC, Andrei Alexandrescu 
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.

And an Iterator doesn't necessarily need an associated Iterable.

I fully recognize how phobos handles ranges, and that it has 
become "the right way" to do things. But I disagree, and I do not 
want the core language to force me to take phobos' approach. I 
greatly appreciate that the only properties of ranges the core 
language cares about are `empty`, `front`, `back`, `popFront`, 
`popBack` - it does not itself imply how `opIndex` and `opSlice` 
are meant to behave for ranges - and I think it should stay that 
way. I see phobos' arrays-as-ranges functions as poor design, and 
most certainly not something that should become inextricably tied 
with the core language.