Issue #28 30 Jun 2016
Written by: Jesse Squires
- SR-1894: Return type of
NSCoding.Protocolis considered ObjC-compatible, but crashes
- SR-1872: Use runloop source in XCTestCase
- SR-1840: Calendar
range(of:, start:, interval:, for:)has incorrect type for start parameter
Commits and pull requests
Saleem Abdulrasool opened a pull request to add PS4 support.
Rintaro Ishizaki improved diagnostics for a trailing closure in a condition statement.
Jamal Rogers resolved SR-1048, a longstanding starter task to support building and testing debug and release builds of swift-corelibs-xctest.
Robert Widmann started work on enabling leaks tracking for the stblib.
The core team is proactively accepting SE-0106 “Add a macOS Alias for the OSX Platform Configuration Test” without a formal review, under the rationale that the proposal is “obvious” and probably should have been treated as a bug fix. Adding aliases for other uses of “OS X” in the language to use macOS are also proactively accepted.
This syntax has been extensively discussed by the community, and is a cornerstone of the “generalized existentials” work for future Swift releases. The community was overall positive on the feature with a few subjective concerns about “&” being tightly associated with bitwise logical operations. The core team believes this will not be contextually confusing since it appears in a type position, between two names that are obviously nominal types (e.g. they are capitalized).
I filed SR-1938 to track implementation of this work, this is a somewhat advanced starter project which would be a great place for someone to dive into the parsing logic in Swift.
Proposals in review
Swift enforces type safe access to memory and follows strict aliasing rules. However, code that uses unsafe APIs or imported types can circumvent the language’s natural type safety. […]
Swift already protects against undefined behavior as long as the code does not use “unsafe” constructs. However,
UnsafePointeris an important API for interoperability and building high performance data structures. As such, the rules for safe, well-defined usage of the API should be clear. Currently, it is too easy to use
For legacy and historical reasons Swift has supported a protocol named
Booleanfor abstracting over different concrete Boolean types. This causes problems primarily because it is pointless and very confusing to newcomers to Swift: is quite different than
Bool, but shows up right next to it in documentation and code completion. Once you know that it is something you don’t want, you constantly ignore it. Boolean values are simple enough that we don’t need a protocol to abstract over multiple concrete implementations.
From a historical perspective, it was a very early solution to the bridging challenge of
BOOL(which comes in as
ObjCBool). In the time since then, Swift has developed a number of more advanced ways to solve these sorts of bridging problems, and
BOOLis already bridged in automatically as
Boolin almost all cases.
Another pragmatic problem with the
Booleanprotocol is that it isn’t used consistently in APIs that take Boolean parameters: almost everything takes
Boolconcretely. This means that its supposed abstraction isn’t useful. The only significant users are the unary
!, and binary
In Swift, a type
Tmay choose to conform to a protocol
Phas associated types that may be used in the protocol requirements. If the associated types are used in the requirements, the types that
Tchooses to bind those associated types to can currently be inferred by the type checker by examining how
Tchooses to implement
The main advantage of removing associated type witness inference is that it decreases the complexity of the type checker. Doing so removes the only aspect of Swift that depends upon global type inference. Simplifying the type checker makes it easier to improve the performance and correctness of the type checker code. Given that both are widely acknowledged issues with current versions of Swift, any opportunity for improvement should be carefully considered.
In the beginning, operators had nice precedence values: 90, 100, 110, 120, 130, 140, 150, 160.
As time went, new and new operators were introduced. Precedence could not be simply changed, as this would be a breaking change. Ranges got precedence 135,
asgot precedence 132.
??had precedence greater than
<, but less than
as, so it had to be given precedence 131.
Now it is not possible to insert any custom operator between
??. It is an inevitable consequence of current design: it will be impossible to insert an operator between two existing ones at some point.
Hey, all. An engineer at Apple noticed the following behavior:
class Foo: NSObject→ exposed to Objective-C, Swift-style (mangled) runtime name
@objc class Foo: NSObject→ exposed to Objective-C, Swift-style (mangled) runtime name
@objc(Foo) class Foo: NSObject→ exposed to Objective-C, unmangled runtime name
@objc class Foo→ illegal, classes must have ObjC heritage to be
They specifically observed that (1) and (2) have the same behavior, and suggested that maybe (2) should be shorthand for (3).
Doug Gregor proposed a draft proposal for
NSError bridging. These changes would dramatically improve error handling interoperability, which is surprisingly more nuanced than you might expect.
Swift bridges between
ErrorProtocol-conforming types and
NSErrorso, for example, a Swift
enumthat conforms to
ErrorProtocolcan be thrown and will be reflected as an
NSErrorwith a suitable domain and code. Moreover, an
NSErrorproduced with that domain and code can be caught as the Swift
enumtype, providing round-tripping so that Swift can deal in
ErrorProtocolvalues while Objective-C deals in
However, the interoperability is incomplete in a number of ways, which results in Swift programs having to walk a careful line between the
ErrorProtocol-based Swift way and the
NSError-based way. This proposal attempts to bridge those gaps.
A new section in proposal, Complications with private types, explains the behavior of private types in detail.
And finally — 🤔 the Swift compiler is like a lamp… 😂