`set` `Iter` method is expensive for large sets

[rickb777]

Because the set Iter method copies the keys into a slice, it will perform poorly for large sets, requiring a larger memory footprint and taking time to make the copy.

It may be possible to have a rangeable sequence generator that 'eats' the input set by using range to take one value at a time, immediately delete that value from the set, and return that value via the Val() T method. This would trade off the reduction in memory footprint against the need to drain the set to empty. In some cases, this might be preferable.

The method providing this behaviour might be called LazyIter to indicate its difference from the existing Iter method.

[rickb777]

The documentation for the Iter method ought to be augmented to point out that the keys are copied and there is a cost to this.

[rickb777]

Ideally, the Iter method would not be present on set.Of instances. The Slices method provides an alternative for which the copy operation is more obvious.

i.e given set s, iter.FromSlice(s.Slice()) is exactly equivalent to s.Iter(), but the latter has the disadvantage of a hidden slice in its implementation,

[bobg]

This is a great point, thank you! I've added commentary about this in #20.

As you may know, Go 1.23, which arrives in a few weeks, will include a major new feature, "range over function," that will make this module's iter package obsolete. I'm preparing a successor right now in anticipation. In the new package, the set.Of.Iter method is renamed to All (in keeping with a new convention for container types) and, as you can see here, is implemented in a much more efficient manner (to wit, via for range as you suggested).

[bobg]

Addressed in #20.