This seems a lot like the Dictionary problem. I'm not sure this is bad enough to kill formIndex(before:), though. Indexes aren't supposed to be expensive to copy.

cc @rjmccall, @gottesmm

@belkadan That remark doesn't make any sense to me:

1. What Dictionary problem?

2. The only reason the formIndex methods exist in the first place is to improve performance in the rare cases when the index is expensive to copy

1. The problem that foo[bar][baz] = 2 ends up doing a CoW-copy of all of foo[bar], because we don't know how to "take-and-return" it.
2. Most uses of formIndex will still modify the index in place, just not all of them. In particular, usually the index is in its own variable, not part of a larger thing that's already being passed inout.

We've talked about making non-mutating methods calls semantically borrow `self` instead of semantically copying. Note that that would make the call `g(&i)` ill-formed as an exclusivity violation.

In general, I see no way that we can both remove the copy of `self` and allow `&self.i` to be passed off simultaneously, because obviously mutating `self.i` can invalidate parts of `self`. So is that just a convenience for your reduction, or is it core to the pattern you need? I wouldn't think that collections usually store indices into themselves, but if you tell me that's important, I will believe you.

@rjmccall This is a reduction of https://github.com/dabrahams/KillSequence/blob/master/GeneratorCollection.swift#L318 .

Most collections don't store indices, but slices do.

I'm afraid I don't understand what you mean about invalidation.

formIndex will still modify the index in place, just not all of them

Good point (reminds self not to file bugs while sick).

But the slices you're talking about presumably also store their parent collection and could presumably advance the index using that instead.

The invalidation issue is just that there's a real exclusivity issue here: you want to pass a field of `self` by mutable reference while also passing all of `self` by immutable reference. The latter can observe changes made to the former.

The SubSequence in the code referenced does not store its parent collection. If it did, it would keep buffers alive longer than necessary.

I see what you mean about the exclusivity problem, now, thanks.

> The SubSequence in the code referenced does not store its parent collection. If it did, it would keep buffers alive longer than necessary.

Oh, right, of course. But in this case you should be able to advance the index without needing the collection.

Yep, that's my fallback. So I think this bug is bogus and will close.