spec: clarify deletion of map entries during iteration

[gopherbot]

by peterbourgon:

In the spec, under "For statements", the topic of deleting map entries during
iteration is addressed with only the sentence:

> If map entries that have not yet been reached are removed during iteration, the
corresponding iteration values will not be produced.

This program appears to work fine:

> http://play.golang.org/p/P-O47Wp2LF

But the spec doesn't seem to *guarantee* that it will work. If this is guaranteed
behavior, can the spec be clarified? Specifically, can this sentence (or one like it) be
added:

> The current entry in a map iteration may be safely deleted.

[dsymonds]

Comment 1:

I'm not sure what you're concerned about. There's no "current" entry in a map. A map
iteration produces a sequence of map entries, but once it gets to an entry and executes
the loop body then it is finished with that entry; it won't produce it again for the
same reason that it won't produce duplicate map entries without any deletions.
The spec describes the cases for mutating the map, specifically deleting an entry that
hasn't been seen yet (it won't yield it) and adding an entry (it might yield it).

Labels changed: added documentation.

Owner changed to @griesemer.

[gopherbot]

Comment 2 by pb@soundcloud.com:

My concern is that the sequence of map entries produced by an iteration may become
corrupted or invalid by mutating the map entry membership in the middle of the iteration.
The spec describes *some* cases of mutating the map in the middle of the iteration. The
case of deleting an entry that has already been (or is currently being) observed isn't
covered.

[ianlancetaylor]

Comment 3:

I don't think any change is required here.  The suggested change doesn't work, since
there is no "current" entry--there are no iterators here.  I think what you are asking
for is something like "range over map will not break in a surprising manner" but I don't
see why it is necessary to state that explicitly.  Ranging over a map works.  It's
necessary to explain what happens with a new entry or a deleted entry that has not yet
been seen, because those cases are not obvious.  It's not necessary to explain what
happens for a deleted entry that has already been seen; that case is obvious.

[griesemer]

Comment 4:

I agree with dsymonds and iant. The spec is pretty clear about what happens. Once a map
entry has been produced, it has been produced. It won't be produced again, whether you
delete it or not. Adding the suggested sentence is akin to saying "a = a - 1" will not
corrupt the value of a.
I suspect what you are concerned about is perhaps something else (and your example -
which can be simplified to http://play.golang.org/p/pA0CQHoHvb btw. - is not necessarily
a good test case): It is possible to construct programs where elements are deleted
depending on specific events, and the outcome (the resulting set elements, not just the
iteration order) is not deterministic because the map iteration order is not specified.
Here's an example:
http://play.golang.org/p/YGTThFIANO
NOTE: you must run this outside the playground since the playground always produces the
same (unspecified) iteration order at the moment.
In this example, you get different resulting sets depending on the iteration order.
Furthermore, you may even get different sizes of sets.
But again, there's nothing wrong with the spec, and if you don't want the unspecified
result in this case, you need to first sort the set keys and iterate in a specific order.

Status changed to WorkingAsIntended.