> On Mar 8, 2016, at 11:49 AM, Dave Abrahams via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> on Tue Mar 08 2016, plx <swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>> wrote:
>
>>> On Mar 3, 2016, at 3:28 PM, Dmitri Gribenko <griboz...@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._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
