This entry point is used in conditional downcasts (as?) to attempt to
bridge from an Objective-C class down to a specific native type (e.g.,
array, dictionary), bridging all elements eagerly so that it can
produce nil if the bridging would fail.
This is the scaffolding for <rdar://problem/17319154>, and makes the
example there work, but there is much more cleanup and optimization to
do.
Swift SVN r18999
This means that we'll get deferred checking of array and dictionary
downcasts when writing "arr as Derived[]",
"(dict as? Dictionary<DerivedKey, DerivedValue>)!", etc, when the
collection can do so.
This is both a general optimization and also staging for
<rdar://problem/17319154>.
Swift SVN r18975
s/_dictionaryCheckedDownCast/_dictionaryDownCastConditional/g
s/_dictionaryBridgeFromObjectiveC/_dictionaryBridgeFromObjectiveCConditional/g
Swift SVN r18931
This is only for the frontend, not for stdlib. The implementation is very
slow, optimizing it is the next step.
rdar://16755123 rdar://16013860
Swift SVN r18928
Sorting was a bit of a mess; we had sort functions doing in-place
mutation /and/ returing the value, and people were confused by the
asymmetry of Array's sort() method with other higher-level methods.
Fixes <rdar://problem/17185815> sort([]T, f) mutates the original array
<rdar://problem/17225190> The Array.sort() method should return a sorted array
Swift SVN r18922
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
used. Fix this by adding them to the GCD overlay. A more general solution is tracked in rdar://17245039,
but that isn't on the critical path right now.
Swift SVN r18916
This is an inefficient, copying implementation of
_dictionaryBridgeToObjectiveC to aid progress on wiring up dictionary
downcasting <rdar://problem/16847470>. Making this implementation
efficient is tracked by <rdar://problem/16852016>.
Swift SVN r18897
This is an inefficient, copying implementation of
_dictionaryCheckedDownCast to aid progress on wiring up dictionary
downcasting <rdar://problem/16847470>. Making this implementation
efficient is tracked by <rdar://problem/16852016>.
Swift SVN r18896
This introduces _dictionaryUpCast and _dictionaryBridgeToObjectiveC,
which will be used for upcasting for non-bridged and bridged key/value
types, respectively. _dictionaryUpCast is a horrible copying O(n)
implementation where we should be able to provide an O(1)
implementation, and _dictionaryBridgeToObjectiveC is similarly
awful. Hence, this is not for <rdar://problem/16852016>, but is merely
a stub to let us make progress on upcasting in the frontend
(<rdar://problem/17289296>).
Swift SVN r18867
instead of importing them as _Nil (which will be going away when nil becomes an expr).
You now get an error saying:
error: 'NULL' is unavailable: use 'nil' instead of this imported macro
This is pretty cool all around, except for the GCD macros that need to be fixed, I'll
handle that as a follow-up.
Swift SVN r18747
Narrowly address the problem of downcasting an array to an array of
Objective-C existentials by checking conformance for Objective-C
protocols. Addresses <rdar://problem/17165071>, but this area still
needs a lot of work.
Swift SVN r18745
rangeOfCharacterFromSet(_:options:range:)
The underlying Objective-C API could return an NSRange of NSNotFound. Swift's
String.Index can not represent that, so change the API to return an optional
Swift Range<Index> instead.
Swift SVN r18679
stringWithBytes(_:length:encoding:) was passing an array to Objective-C
incorrectly, and a garbage NSString was being constructed as a result.
Unhide the initializer was accidentally hidden.
Swift SVN r18674
Two of the String conversion tests want to check the case where none of CF's
fast-access functions succeed. In one of these tests CF's fast-access functions
will always succeed when CF does not support tagged pointer string objects.
That breaks the test on platforms that don't support tagged pointer strings.
The test now does nothing if it does not get an NSTaggedPointerString back.
Swift SVN r18666
Our runtime doesn't fix up class field offset vectors for resilient ObjC base classes, causing the offsets to be wrong if the actual size of the base class differs from its compile-time claimed size. Use the ObjC runtime's ivar records instead if the class has ObjC heritage. We can't do this all the time because the ObjC ivar records aren't yet trustworthy for generic classes, but we don't fully support the mix of ObjC heritage and genericity very well anyway yet. Fixes <rdar://problem/17027510> in the short term.
Swift SVN r18622
