Dictionary's isBridgedToObjectiveC() was overly restrictive. This went
unnoticed because the tests were using internal Dictionary APIs to construct
the desired state, instead of going thourgh casts.
rdar://16973429
Swift SVN r18454
This bug was a result of code drift between the hand written assembly
and the generic code. Thankfully we disabled the hand written assembly a
while a go, which made this bug easier to find.
This fixes: <rdar://problem/16954674>
Swift SVN r18425
We were using the bridged non-verbatim path
(_arrayBridgeFromObjectiveC) for bridged-verbatim types. While that
path can do the right thing (and does when the standard library's
internal checking is turned off), it's unnecessarily inefficient.
Swift SVN r18418
This makes fun bridging like
var obj: AnyObject! = [3.14159, 2.71828, 0] as Double[]
if let intArr = obj as Int[] {
println("Array of doubles as ints is \(intArr)")
}
"work", given that NSNumber is the common class type through which we
are bridging.
Swift SVN r18398
Unfortunately, we can't add an implicit conversion from
String to CFString, or anything analogous like string
literal support, without introducing ambiguities
when converting to AnyObject.
rdar://16271682
Swift SVN r18387
By beating the compiler into submission with a "bouncing through
non-methods" method, I have made it accept my crazed intention that
Array and friends should interoperate with all Sequences and
Collections! Filing <rdar://problem/16954833> to document the failure
of the method method.
Swift SVN r18378
This entry point is used when T is bridged verbatim and U is bridged
non-verbatim. It attempts to bridge each T from Objective-C to a U,
and returns nil if any of the elements cannot be bridged back to a U.
For now, only _convertNSArrayToArray and Array.bridgeFromObjectiveC
depend on this. It will soon be used for checked casts from, e.g.,
AnyObject[] to String[].
This is part of <rdar://problem/16952771> and general array bridging.
Swift SVN r18369
In a naive implementation of a Sequence adapter, adapting a
non-self-destructive (multi-pass) Sequence having a reference-semantics
Generator produces a self-destructive adapted view. This is technically
correct because Sequences are allowed to be self-destructive, and
theoretically every multi-pass Sequence would be a Collection. However
Sequences are much easier to build than Collections, so users are likely
to make them, and it would be extremely surprising if adapting a
self-preserving Sequence yielded a self-destructive one.
Swift SVN r18350
It was too easily confused with IndexingGenerator, which, come to think
of it may be obsolete. It's just a PermutationGenerator with
startIndex..endIndex in the indices sequence.
Swift SVN r18341
As declared, Dictionary's keys and values were private. Instead of
hiding Map away as _Map, give it a "nice" verbose name and expose it
through a "nice" lowercase global function called map(), which we
overload so it works on both Collections and Sequences, returning a
Collection when that's what it started on.
We'll follow this pattern for filter, which was requested on Array. The
implementation is easy once you have a lazy view!
Swift SVN r18340
