Kate Stone writes on the Swift.org blog:

We are delighted to introduce Xcode Playground Support as part of the Swift open source community!

Swift developers can approach the language in many different ways. In addition to the traditional command-line compiler and interactive REPL one of the earliest experiences for many developers was through the introduction of playgrounds in Xcode. Prior to Swift 3.0 and Xcode 8 this was only possible with the version of Swift included with Xcode. The Xcode Playground Support project enables building a Swift toolchain that includes everything necessary to integrate with the Xcode 8 playground experience. Playground Support will be included in corresponding snapshots. Download a snapshot, install it, and select the toolchain to work with the latest Swift features in Xcode playgrounds.

The Playground Support source code can be found here (thanks, Jordan!) So far, my very favorite bit comes from Woodchuck.swift, part of the PlaygroundLogger module:

//
//  Woodchuck.swift
//  PlaygroundLogger
//
//  Copyright (c) 2014-2016 Apple Inc. All rights reserved.
//

// “How much logging could a PlaygroundLogger log if a PlaygroundLogger could log logs"

Admittedly there’s not a lot of “there” there, but it’s still great to see what’s available.

Mandatory Disclaimer: This does not fall under the scope of Swift 3 timeframe as it is entirely additive

I love literals. Right now, in addition to the protocols that allow types to adopt literal expression, Swift offers three special literals: #colorLiteral(red:,green:,blue:alpha:), #fileLiteral(#imageLiteral(resourceName:), and #imageLiteral(resourceName:).

Literals do not have types. They are evaluated and their types inferred from the context in which they are used. For example:

I literally (sorry, pun intended) cut and paste the code from the iOS playground to the OS X/macOS playground.

The same source line (let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)) established a UIColor in one case and an NSColor in the other. In both examples, the integer literal “1” resolved to Double type inference.

Introducing language literals creates typeless universal representations that cross operating systems and exist independent of implementation details. Examples of these typeless concepts include numbers, file paths, images, and colors (not to mention arrays, truth values, etc).

So what can Swift introduce next?

While I’d love to see Bezier paths, I’m not sure there’s a way to do this cleanly. If you notice, in the existing literals, all fields are declared in the initializer. Although Bezier paths use essentially universal components, they require multistage creation.

A Bezier path consists of a series of move to, line to, quad curve to, cubic curve to, and close. (Other features like “remove all points” are simply gravy.) If Swift could offer a literal Bezier, at best it could construct a single empty instance, or a fixed set of predefined instances like an oval, square, line. Neither is particularly satisfying:

let myBezier = #bezierLiteral()
let myBezier = #bezierLiteral(.oval, rect:)

There is, as far as I know, no such thing as a typeless method that would allow universal construction:

let myBezier = #bezierLiteral()
myBezier.#bezierMoveTo(point:)
myBezier.#bezierLineTo(point:)

You could work around this by limiting Bezier literals to load from common vector graphic formats stored in a file, just as #imageLiteral now allows you to load graphics. If you really want to stretch, you could take that same approach to load style sheets, enabling you to construct attributed strings. (Or introduce #jsonLiteral)

Moving to more reasonable and achievable goals, I think Swift could easily allow literals for core geometry (rects, points, sizes, vectors, transforms), that would apply across 2D and 3D applications, allowing you to use the same literals regardless of whether you’re using Quartz, Accelerate, GameplayKit, simd, and so forth.

I think Swift would also allow simple adoption of literals for sounds, URLs, and dates (at least those using the Unix epoch, rather than Apple’s epoch).

What other targets of opportunity can you think of that would simplify cross-platform development through Swift literals? Let me know.

@ericasadun add #fontLiteral to your list 😉

— Matthew Johnson (@anandabits) July 8, 2016

Hi Erica,

I was curious if you had a more elegant solution for this particular situation in Swift: Say you want to check that a specific variable is nil before continuing; it’s much more common to do the opposite. Right now, I have something like:

guard thing == nil else {
   if let thing = thing {
      doSomething(withThing: thing)
    }
   return
}

Is there a better way to do this? I could change to an `if` statement, but I like that the guard statement insures I have to exit. Logically, it would be safe to force-unwrap, but meh.

– Rob

Rob, yes, there’s a much easier approach. You’re using guard here as a kind of “if statement” and that’s backwards to the way it’s intended. Instead, use guard to unwrap the “thing” and it that fails exit scope. If a your guard statement’s “else” clause is significantly larger than a line or two, you’re probably doing things wrong.

Here’s the correct way to do it:

guard let thing = thing else { return } // leave scope if thing cannot be unwrapped
doSomething(with: thing) // thing is now unwrapped

This updated code follows a common Swift pattern: use a guard statement to shadow an optional value. Variable shadowing with guard enables you to use the same name (“thing”) in the current scope. Once you pass that guard statement, your item is unwrapped and can be used without further testing against nil.

You are right to avoid forced unwrapping. Challenge yourself to justify each and every exclamation point in your code.

Accepted

SE-0110: Distinguish between single-tuple and multiple-argument function types is accepted. “Swift’s type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments. The current behavior violates the principle of least surprise and weakens type safety, and should be changed.” Team writes:

The community and core team agree that this proposal is the right thing to do, and many agree that this could probably have been treated as a bug fix on a previous proposal.

SE-0011: Remove type system significance of function argument labels is accepted. “Swift’s type system should not allow function argument labels to be expressed as part of a function type.” Team writes:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels.  In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section).  The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

SE-0113: Add integral rounding functions to FloatingPoint is accepted. “The standard library lacks equivalents to the floor() and ceil() functions found in the standard libraries of most other languages. Currently, we need to import Darwin or Glibc in order to access the C standard library versions. In general, rounding of floating-point numbers for predictable conversion in to integers is something we should provide natively.” Team writes:

The community and core team agree that this proposal helps to “round out” the other Swift 3 numerics work. One minor revision is necessary to make the proposal implementable in Swift 3. Since protocol requirements cannot currently have default arguments, the desired behavior should be achieved with two overloads of each operation:

protocol FloatingPoint {
...
/// Returns a rounded representation of `self`, according to the specified rounding rule.
func rounded() -> Self
func rounded(_ rule: RoundingRule) -> Self

/// Mutating form of `rounded`.
mutating func round()
mutating func round(_ rule: RoundingRule)
}

Where the no argument cases can be implemented with a protocol extension that forwards to the single-argument versions.

SE-0077: Improved operator declarations is accepted. (1st version) “Replace syntax of operator declaration, and replace numerical precedence with partial ordering of operators” However many reviews it takes, this is a good one to get right. Team writes,

This round of feedback focused on naming, both of the attributes for precedence groups and the conventions to use for naming the groups themselves:

The community expressed a strong preference for ‘higherThan’ and ‘lowerThan’ precedence relationships over the previously-proposed ‘strongerThan’ and ‘weakerThan’, and the core team *agrees* that these are better terms of art. The proposal is accepted with these terms revised.

The standard library team reviewed the proposed names for the standard precedence groups, and suggests the following minor naming revisions:

• AssignmentPrecedence
• TernaryPrecedence
• DefaultPrecedence
• LogicalDisjunctionPrecedence
• LogicalConjunctionPrecedence
• ComparisonPrecedence
• NilCoalescingPrecedence
• CastingPrecedence
• RangeFormationPrecedence
• AdditionPrecedence
• MultiplicationPrecedence
• BitwiseShiftPrecedence

establishing a convention of <Noun>Precedence for precedence group names. The core team accepts the proposal with these revised standard precedence names.

Rejected

SE-0108: Remove associated type inference is rejected. “To simplify the compiler and typechecker, we propose to remove associated type witness inference [to] 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.” Team writes:

The community and core team agree that removing this feature will impose an unacceptable user experience regression for developers using Swift generics, including important protocols like Collection.  While we all seek the simplifications to the compiler internals that the proposal would allow, we will have to consider other approaches to achieving that in subsequent releases.

Active Review

• May 9…16 SE-0086: Drop NS Prefix in Swift Foundation “As part of Swift 3 API Naming and the introduction of Swift Core Libraries, we are dropping the NS prefix from key Foundation types in Swift.”
• July 7…12 SE-0091: Improving operator requirements in protocols (Second review) “When a type conforms to a protocol that declares an operator as a requirement, that operator must be implemented as a global function defined outside of the conforming type. This can lead both to user confusion and to poor type checker performance since the global namespace is overcrowded with a large number of operator overloads. This proposal mitigates both of those issues by proposing that operators in protocols be declared statically (to change and clarify where the conforming type implements it) and use generic global trampoline operators (to reduce the global overload set that the type checker must search).”
• June 28 … July 10 SE-0107: UnsafeRawPointer API “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.” This extensive redesign addresses many issues under the microscope.
• June 28 … July 4 SE-0109: Remove the Boolean protocol “For legacy and historical reasons Swift has supported a protocol named Boolean for 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.”
• June 30 … July 4 SE-0112: Improved NSError Bridging “Swift bridges between ErrorProtocol-conforming types and NSError so, for example, a Swift enum that conforms toErrorProtocol can be thrown and will be reflected as an NSError with a suitable domain and code. Moreover, an NSError produced with that domain and code can be caught as the Swift enum type, providing round-tripping so that Swift can deal in ErrorProtocol values while Objective-C deals in NSError objects. 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.”
• July 1…7 SE-0114: Updating Buffer “Value” Names to “Header” Names  “This proposal updates parameters and generic type parameters from value names to header names for ManagedBuffer, ManagedProtoBuffer, and ManagedBufferPointer. All user-facing Swift APIs must go through Swift Evolution. While this is a trivial API change with an existing implementation, this formal proposal provides a paper trail as is normal and usual for this process.”
• July 1…7 SE-0115: Rename Literal Syntax Protocols “This proposal renames the *LiteralConvertible protocols to ExpressibleBy*Literal.” (I proactively changed the ExpressibleAs to ExpressibleBy in this description. It is not part of the original proposal but it makes the rename comprehensible.)
• July 5…11 SE-0116: Import Objective-C id as Swift Any type “Objective-C interfaces that use id and untyped collections should be imported into Swift as taking the Any type instead of AnyObject.”
• July 5…11 SE-0117: Default classes to be non-subclassable publicly “Since Swift 1, marking a class public provides two different capabilities: it allows other modules to instantiate and use the class, and it also allows other modules to define subclasses of it. This proposal suggests splitting these into two different concepts. This means that marking a class public allows the class to be used by other modules, but does not allow other modules to define subclasses. In order to subclass from another module, the class would be marked subclassable. Relatedly, Swift also conflates two similar concepts for class members (methods, properties, subscripts): public means that the member may be used by other modules, but also that it may be overriden by subclasses. This proposal introduces a new overridable modifier, which is used instead of public on members that are overridable.”
• July 5…11 SE-0118: Closure Parameter Names and Labels “We propose a revision to the names and argument labels of closure parameters in standard library APIs.” I unleashed the full force of my opinion on this one, I’m pretty happy with the proposed renames.

Because reasons. (Thanks to Mike Ash for reminding me of the flatMap trick and for suggesting AnyIterator instead of AnySequence.)