The latter has some brilliant code to deal with differing levels of
optionality, binding inner optionals etc. Unifying these code paths
makes array downcasts work when the source has (possibly
implicitly-wrapped) optional type, e.g.,
var arrImplicitOpt: AnyObject[]! = nsarr
if let strArr = arrImplicitOpt as String[] {
println("String array contains \(strArr)")
} else {
println("Not a string array")
}
Another part of <rdar://problem/16952771> and the array-bridging story.
Swift SVN r18392
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
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
Added a workaround for <rdar://problem/16953026> that allows them to
pass and flipped the sense of a test that was failing because we can now
downcast an Array that we couldn't downcast before.
Swift SVN r18319
upcasts."
Reinstate "Restrict the array-bridged conversion to non-verbatim
bridging."
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Move _arrayBridgedDownCast to Foundation"
Reinstate "Replace "can" with "cannot" in a message."
Reinstate "Implement support for non-verbatim T[] -> AnyObject[]
upcasts."
This reinstates commit r18291.
This reinstates commit r18290.
This reinstates commit r18288.
This reinstates commit r18287.
This reinstates commit r18286.
This reinstates commit r18293.
This reinstates commit r18283.
John fixed the issue in r18294.
Swift SVN r18299
Revert "Restrict the array-bridged conversion to non-verbatim bridging."
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Move _arrayBridgedDownCast to Foundation"
Revert "Replace "can" with "cannot" in a message."
Revert "Implement support for non-verbatim T[] -> AnyObject[] upcasts."
This reverts commit r18291.
This reverts commit r18290.
This reverts commit r18288.
This reverts commit r18287.
This reverts commit r18286.
This reverts commit r18293.
This reverts commit r18283.
Sorry for the number of reverts, but I needed to do this many to get a clean
revert to r18283.
Swift SVN r18296
One of my recent type-checker changes starting passing all array
upcasts, including "bridged" ones like String[] -> AnyObject[],
through the library entry point _arrayUpCast, which is only meant for
class/ObjC existential types that are bridged verbatim.
Fixes part of <rdar://problem/16952238>; more cleanup to follow.
Swift SVN r18283
