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.)
getBytes still lacks the ability to take an optional buffer, but Ali
agrees that we can leave that off for this release in light of the fact
that we have lengthOfBytesUsingEncoding.
Swift SVN r31223
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
containsString and localizedCaseInsensitiveContainsString were
introduced in 10.10, release-noted, but never
documented (<rdar://22236574>), so we missed them.
Fixes <rdar://18776075> String.containsString doesn't work in Swift
Swift SVN r31152
