An index of a FlattenCollection is composed of two: an index to the
current chunk and an index within that chunk. So you take the
startIndex, and advance it to the second chunk; call the result idx1.
You take startIndex again, and advance it the same number of steps; call
the result idx2:
let idx1 = flatMapCollection.startIndex.advancedBy(10)
let idx2 = flatMapCollection.startIndex.advancedBy(10)
idx1 and idx2 have to compare equal according to collection and index
axioms. But this can't be cheaply implemented. Every index contains an
index into the inner collection. So indices into two collections with
the same elements have to compare equal even though the collections
don't have any common history, they were merely created using the same
sequence of steps.
What currently happens is that you get random results depending on the
underlying collection kind.
rdar://21989896
Swift SVN r30617
FlattenCollection used to evaluate the closure three times per element.
That's acceptable from the technical standpoint, given its lazy
semantics, but not acceptable in practice. This commit fixes it to only
evaluate it two times when it is converted into an array.
This commit also improves tests. The new checks used to fail before the
standard library was fixed.
But there are larger issues with FlattenCollection -- it does not model
CollectionType properly. See next commit.
Swift SVN r30616
Otherwise, we end up with declarations with public access that do not
have public 'self' types. These declarations can then be used by other
modules, which may end up trying to access non-external symbols.
This closes a loophole currently in use by the standard library, so
the '_prext_ReverseIndexType' and '_ReverseCollectionType' protocols
become public for now. In order to keep the API impact minimized,
extensions involving these protocols now extend them directly, so that
all of the "private" stuff shows up in one place in the generated
interface. This is not a long-term solution, but it's no worse than
the rest of the underscore rules in the standard library.
rdar://problem/21380336 tracks relaxing access restrictions for protocol
conformances when the witnesses come from a different type, like a
protocol extension. This requires some SILGen work to do correctly.
Finishes rdar://problem/21559986
Swift SVN r30612
This covers:
- Lifetime-extending wrappers, like withExtendedLifetime, withCString, and withUnsafe*Pointer
- 'map' and friends on Optional
- 'indexOf'
A few APIs I haven't gotten to yet in this first pass:
- Autoclosure APIs, like assert, &&, etc.
- the 'isOrderedBefore' predicate for sorting APIs. The sorting implementation does some microoptimizations with 'inout' closures that violate rethrows checking.
- Strict 'map', 'filter', and friends on CollectionType. These need some plumbing in Lazy to be able to thread a Result-forming transformation through.
Swift SVN r30597
These types are leftovers from the early pre-1.0 times when Int and UInt
were always 64-bit on all platforms. They serve no useful purpose
today. Int and UInt are defined to be word-sized and should be used
instead.
rdar://18693488
Swift SVN r30564
They pass various operations through to the base
collection (e.g. LazyMapCollection's .count) and thereby avoid taking
the potentially-slower path through the default implementation.
Swift SVN r30554
Add a default implementation for CollectionTypes where their SubSequence
== Self. That is, mainly, Slice and ArraySlice. This changes the slice's
view of, but not modifying or copying, the underlying collection.
rdar://problem/20302034
Swift SVN r30496
The lazy components, in particular generators and indices, need to offer
access to their base values so they can be mapped back into the
underlying sequences and collections. Along the way, give some love to:
* documentation comments
* argument labels for predicates
* not storing unneeded properties
* public constructors where appropriate
Swift SVN r30460
- De-underscore the API that takes an equatable separator, add doc
comment, and add a test for it.
- Add a test for the negative maxSplit case.
- Add lifetime tracker for isSeparator closure in the semantic test.
Swift SVN r30413
If the start of the ring buffer is aligned at the left, just wrap the
whole thing directly in an AnySequence and return it. Otherwise, return
a lazy concatenation of the the two slices of the ring buffer. This
prevents a forced full copy of the result.
rdar://problem/21885925
Swift SVN r30374
rdar://problem/21663830
Add the following new requirements to SequenceType with default implementations:
- dropFirst(n)
- dropLast(n)
- prefix(n)
- suffix(n)
- split(n)
In addition, provide specialized default implementations of these for CollectionTypes with forward, bidirectional, and random-access Index types where possible.
Add the following new requirements to CollectionType with default implementations:
- prefixThrough(n)
- prefixUpTo(n)
- suffixFrom(n)
- split() // isSeparator closure
Add the following convenience APIs:
- dropFirst() -> calls dropFirst(1)
- dropLast() -> calls dropLast(1)
Add a tentative underscored API:
- split() // takes Equatable separator.
Some APIs have undefined behavior when creating slices where the endpoints go beyond the bounds of the underlying collection. This will be fixed later by trapping creation of slices with invalid indices (rdar://problem/21822657).
Swift SVN r30371
We used to be only propagating laziness through reverse collections when
the base collection was a LazyCollection<T>, rather than all
LazyCollectionType's. Also updated the flatten tests to check for the
same issue.
Swift SVN r30367
