[swift-evolution] [RFC] New collections model: collections advance indices

[plx]

> On Mar 8, 2016, at 11:49 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> on Tue Mar 08 2016, plx <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>> On Mar 3, 2016, at 3:28 PM, Dmitri Gribenko <gribozavr at gmail.com>
>>> wrote:
>> 
>> I think it’s possible to adjust the protocol hierarchy to “reserve
>> room”—remove `Indexable`’s methods from `Collection`, add them back to
>> a new `ForwardCollection` between `Collection` and
>> `BidirectionalCollection`—but it’d only make sense to do that if you
>> expect to have use for that room in the future.
> 
> This is something we expressly don't do in generic programming.
> Protocols (concepts) are spawned only by the existence of real-world
> use-cases, and enough of them to make the generality worthwhile.

Apologies for the long delay in replying. I’ll keep this somewhat brief b/c:

- it’s been almost a month
- it’s perfectly-feasible for me to tack-on my own little hierarchy for my own needs, if necessary

…so even though I would personally *prefer* that `Collection` be defined as *having-a* canonical linearization (as opposed to *being-a* linearization), it doesn't seem to be of pressing concern.

I do, however, have an alternative proposal: would it be possible to have `Collection` support some methods like these (but with less-atrocious naming):

  // MARK: Basic “Unordered” Iteration

  /// Like `forEach`, but need not *necessarily* visit elements in the same order as you would
  /// see them in a for-in loop; meant for use for when all you need is to visit each element in *some* order.
  func unorderedForEach(@noescape visitor: (Self.Generator.Element) throws -> Void) rethrows

  /// Type of the sequence for `unorderedElements`; a default that is `== Self` seems reasonable.
  associatedtype UnorderedElementSequence: Sequence where UnorderedElementSequence.Generator.Element == Self.Generator.Element

  /// Returns a sequence that visits all elements in `self` in *some* order, but not
  /// necessarily the same order as a for-in loop (and not *necessarily* the same
  /// ordering as-in `unorderedForEach`…)
  func unorderedElements() -> UnorderedElementSequence

…and perhaps also some methods like these:

  // MARK: “Unordered” Enumeration (Index + Element)

  /// Like `unorderedForEach`, but the closure is given `(indexOfElement, element)` rather than
  /// just `element` itself; the name here is terrible in particular. No guarantee the ordering is
  /// the same as the ordering for unorderedForEach
  func unorderedEnumeratedForEach(@noescape visitor: (Self.Index,Self.Generator.Element) throws -> Void) rethrows

  /// Type of the sequence for `unorderedEnumeration `; a default that is identical to what `self.enumerate()` returns seems reasonable.
  associatedtype UnorderedEnumerationSequence: Sequence where UnorderedElementSequence.Generator.Element == (Self.Index,Self.Generator.Element)

  /// Returns a sequence that visits all pairs of `(indexOfElement, element) in `self` in *some* order, but not
  /// necessarily the same order as a for-in loop.
  func unorderedEnumeration() -> UnorderedEnumerationSequence

…?

If you want a motivating example, suppose you have a k-ary tree-like implemented as a packed array (in the usual way).

Obviously the “standard” for-in/index/etc. iteration should respect the “tree ordering”; but, if all you’re doing is this:

  // or `for view in contentViews`...
  contentViews.forEach() { $0.hidden = false }

…it’d be nice to be able to write something like this:

  // or `for view in contentViews.unorderedElements()`...
  contentViews.unorderedForEach() { $0.hidden = false } 

…to avoid paying the cost of visiting things in order?

For concrete types you can always define such methods and call them when appropriate, but I think it’d be very handy to have such methods available in generic contexts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160408/16331620/attachment.html>