We were using a precondition which crashes the program when invalid input is
provided. We want to provide a way to gracefully check and handle invalid input
or shutdown the program if necessary.
SR-1930
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
Foundation provides a number of specific operators defined in the
global scope. Push all of these into their corresponding types. This
cleanup helps verify that the SE-0091 implementation is generally
functional.
We currently specify a few internal ObjC classes. This commit ensures that they can not be accidentally exposed (and thus need to be supported) into the future. Luckily, NSData and NSDictionary/NSMutableDictionary already specify classForCoder in a general way. NSCharacterSet does not.
This commit also establishes unit tests to ensure all three types do not regress from this into the future.
Also, for completeness, it ensures classForArchiver and classForKeyedArchiver return appropriately as well.
Use the portable spelling for the nullability keywords (_Nullable, _Nonnullable,
_Null_unspecified) rather than the old spelling (__nullable, __nonnullable,
__null_unspecified). NFC.
Safely unwrap two optionals used in the compare that follows.
NFC, but this (or another work-around) will be required if either
SE-0121 or SE-0123 is approved.
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 46a9f57329.
This broke Swift CI, OSS incremental RA:
./swift/stdlib/public/SDK/Foundation/TimeZone.swift:228:45: error: 'NSTimeZone' is not implicitly convertible to 'TimeZone'; did you mean to use 'as' to explicitly convert?
return lhs._wrapped.isEqual(to: rhs._wrapped)
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
This reverts commit 9c1f21bdf0.
This breaks swift-ci for everyone:
stdlib/public/SDK/Foundation/Calendar.swift:426:74: error: 'DateInterval' is only available on iOS 10.0 or newer
public func dateInterval(of component: Component, for date: Date) -> DateInterval? {
As part of the extensive work on value types in Foundation this year, we
decided to also add value types for these three key classes. In addition
to adding value semantics, the API was extensively audited to improve
Swift interop (especially Calendar).
rdar://26628184
Second pass at updates for SE-0086 feedback
<rdar://problem/26892977> Make sure NSOrderedSet keeps its NS
<rdar://problem/26880016> NSBundleResourceRequest should keep its NS
<rdar://problem/26892958> Make sure NSAttributedString keeps its NS
<rdar://problem/26653694> NSCoder.decodeTopLevelObjectForKey does not follow naming guidelines
<rdar://problem/27355801> Foundation should have a structural type for TextCheckingResult
<rdar://problem/26770611> NSExpression naming is a bit awkward in swift
<rdar://problem/26653451> NSCoder encodeDataObject is misleading
<rdar://problem/26653653> NSCoder decodeObjectOfClass is redundant
Previously, a type that conformed to 'Error' could not be bridged to
NSError directly. Rather, one would have to go through the 'Error'
protocol, e.g.,
myErrorValue as Error as NSError
rather than
myErrorValue as NSError
Make the latter work.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
