The preferred way to create a nil pointer is to use the 'nil' literal.
Affected types:
AutoreleasingUnsafeMutablePointer
OpaquePointer
UnsafeMutablePointer
UnsafePointer
Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
Adding a conformance to Foundation doesn't work because NSString can
be used without loading Foundation. debugDescription is one example of
this.
The only value we derive from the _CocoaStringType is its name, which
makes some APIs more readable. Adding a type safe wrapper around it
serves no purpose since we're almost always immediately casting back
and forth from an 'id'. This was previously done with unsafeBitCast,
which should be avoided unless we really need to reinterpret a bit
pattern.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
Like decodeTopLevelObjectOfClass(_:forKey:), this API works very nicely
as a generic method in Swift, and this one is actually the one we expect
to be commonly used. One thing to note here is that these methods are
stricter than their ObjC counterparts: they will do a forced checked cast
even when the unarchiver does not use "secure" coding.
This depends on the previous commit; without it, we do not actually
enforce type safety for these methods.
The API notes change is to make the non-generic version of this method
unavailable so that it does not participate in overload resolution.
Without this we prefer the non-generic method unless there's a contextual
type for the result. I've filed rdar://problem/22243198 to track taking
this out once Foundation has updated their headers.
rdar://problem/17060110 (again)
Swift SVN r31154
ArraySlice indices now map directly onto the collection it is slicing
and maintains that mapping even after mutations.
Before:
var a = Array(0..<10)
var s = a[5..<10]
s.indices // 0..<5
s[0] = 111
s // [111, 6, 7, 8, 9]
s.removeFirst()
s.indices // 1..<5
After:
var a = Array(0..<10)
var s = a[5..<10]
s.indices // 5..<10
s[5] = 99
s // [99, 6, 7, 8, 9]
s.removeFirst()
s.indices // 6..<10
- Refactor some of the internals of the buffer types to make it easier
to read and understand.
- Add Array, ArraySlice, and ContiguousArray to the test suite at the
RangeReplaceable test entry points, subjecting them to the same tests
as all of our collections.
- Update existing test expectations for the indexing changes.
rdar://problem/21866825
Swift SVN r30840
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
Class representation
As Joe explained, when Swift passes a metatype like AnyClass for an type
defined in Objective-C, it will pass the Swift metadata pointer instead
of an id-compatible Class.
Swift SVN r30268
<rdar://problem/21384187> NSDictionary's convenience init(objects:
[AnyObject], forKeys keys: [AnyObject]) is unsound
This method is unsound / unsafe for Swift. There is not a way to
correctly express the alternating variadic type constant:
AnyObject, NSCopying,...
The overlay already defines a tuple based method that serves the same
role.
Patch by Michael J LeHew Jr.
Swift SVN r29497
This makes it clearer that expressions like "foo.myType.init()" are creating new objects, instead of invoking a weird-looking method. The last part of rdar://problem/21375845.
Swift SVN r29375
