[stdlib] Add nonmutating rotated and concatenated collection prototypes

[natecook1000]

What's in this pull request?

This request adds two new wrapping collections as standard library prototypes:

• a concatenated collection that maintains the traversal properties of its two inner collections, and
• a rotated collection view that uses concatenated subsequences of its base collection internally.

Resolved bug number: n/a

---

Before merging this pull request to apple/swift repository:

• Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform	Comment
All supported platforms	@swift-ci Please smoke test
All supported platforms	@swift-ci Please smoke test and merge
OS X platform	@swift-ci Please smoke test OS X platform
Linux platform	@swift-ci Please smoke test Linux platform

Validation Testing

Platform	Comment
All supported platforms	@swift-ci Please test
All supported platforms	@swift-ci Please test and merge
OS X platform	@swift-ci Please test OS X platform
OS X platform	@swift-ci Please benchmark
Linux platform	@swift-ci Please test Linux platform

Lint Testing

Language	Comment
Python	@swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

This one is based on ConcatenatedCollection, which concatenates
two collections with the same element type.

[dabrahams]

Is there a reason this isn’t part of the Algorithms prototype? It seems like there will be some interaction(?)

[dabrahams]

@swift-ci Please test

[karwa]

Was there a swift evo proposal for this? I don't like the idea of having the collection type as one of the generic parameters - it means you will get chains like: 'ConcatenatedCollection<ConcatenatedCollection<Array, ContiguousArray>, Array>', which is not very Swift.

I'd prefer we wait until generics are more fleshed out, so we can represent this as an abstract "CollectionOf" without leaking details of what types were used to construct it.

Edit: ah sorry it's a prototype, my bad. I just saw "public" in the files and assumed this was something that went through quickly before the Swift 3 line dropped.

[dabrahams]

on Mon Jul 18 2016, karwa <notifications-AT-i.8713187.xyz> wrote:

Was there a swift evo proposal for this?

No, prototypes don't require evolution proposals.

I don't like the idea of having the collection type as one of the
generic parameters - it means you will get chains like:
'ConcatenatedCollection<ConcatenatedCollection<Array,
ContiguousArray>, Array>', which is not very Swift.

Actually it is very Swift. That's exactly how reversed(), joined(),
and other similar algorithms are implemented.

I'd prefer we wait until generics are more fleshed out, so we can
represent this as an abstract "CollectionOf" without leaking
details of what types were used to construct it.

While that exposes nice simple type names, it's much less optimizable.
We probably won't be going that way until and unless our compilation
model changes drastically.

Dave

[dabrahams]

Nate, why isn’t it better to flatten a CollectionOfTwo than to expose ConcatenatedCollection?

[natecook1000]

Nate, why isn’t it better to flatten a CollectionOfTwo than to expose ConcatenatedCollection?

I think the only benefit is that we don't have a random-access flattened collection, since the number of sub-collections is unknown. For the rest it seemed easier to implement all the RotatedCollections the same way.

Is there a reason this isn’t part of the Algorithms prototype?

I used a separate file because this seemed like an alternative implementation of some of the ideas in Algorithms.swift. Would you prefer it all together? I can use a prefix or something so the rotated methods don't collide.

[dabrahams]

on Tue Jul 19 2016, Nate Cook <notifications-AT-i.8713187.xyz> wrote:

Nate, why isn’t it better to flatten a CollectionOfTwo than to expose ConcatenatedCollection?
I think the only benefit is that we don't have a random-access
flattened collection, since the number of sub-collections is
unknown.

You can do it if the size of the sub-collections is uniform, or,
technically, if the number of sub-collections is a constant. I guess
when there are two we fall into the latter case. Okay.

For the rest it seemed easier to implement all the RotatedCollections
the same way.

Makes some sense.

Is there a reason this isn’t part of the Algorithms prototype?
I used a separate file because this seemed like an alternative
implementation of some of the ideas in Algorithms.swift. Would you
prefer it all together? I can use a prefix or something so the
rotated methods don't collide.

I thought we agreed that you were improving on some of the things
implemented there.

Dave

[natecook1000]

@swift-ci Please test

[dabrahams]

Thanks for your work on this, Nate!