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
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
These tests trigger a bug in a lazy flatMap() that I will fix in a later
commit, but I want to commit tests separately to show that they pass
with the eager flatMap().
Swift SVN r30559
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
Due to the fact that AnyClass is not Hashable, and that currently
NSKeyedArchiver/Unarchiver work with NSObject-derived, NSCoding
compliant classes, we are marking the decodeObjectOfClasses API refined
for Swift in our objc header and providing the desired overlay in our
overlay as shown below.
Arrays were also considered (for both API), but the underlying
implementation is entirely set-based, and using Arrays in Swift vs Sets
in objective C felt like too far a deviation.
Patch by Michael LeHew Jr.
Changes to the Dictionary test are caused by bumping the Fonudation API
epoch and taking in a fix in the types used in an NSDictionary
initializer.
rdar://21486551
Swift SVN r30297
The way we pass and compose source locations, messages, etc. needs to be
brought under control before too many more tests get written. This is
the first step.
Swift SVN r29928
Remove these standard library types in favor of (T) -> () closures.
It was originally believed that generic optimizations would make these
types profitable, however:
// FIXME: Insert benchmarks here.
rdar://problem/21663799
Swift SVN r29927
Add a shared buffer to every range replaceable mutable collection to
track logical mutations, and invalidate all indices on every mutation.
Swift SVN r29917
