DougGregor

A Possible Vision for Macros in Swift

As Swift evolves, it gains new language features and capabilities. There are different categories of features: some fill in gaps, taking existing syntax that is not permitted and giving it a semantics that fit well with the existing language, with features like conditional conformance or allowing existential values for protocols with Self or associated type requirements. Others introduce new capabilities or paradigms to the language, such as the addition of concurrency or comprehensive reflection.

There is another large category of language features that provide syntactic sugar to eliminate common boilerplate, taking something that can be written out in long-form and making it more concise. Such features don't technically add any expressive power to the language, because you can always write the long-form version, but their effect can be transformational if it enables use cases that would otherwise have been unwieldy. The synthesis of Codable conformances, for ex

CodaFi

Motivation

Swift’s type system supports a number of different ways of taking a function or type and abstracting it. Usually, this is done by adding a generic parameter and an associated set of constraints. Similarly, a function that takes a particular type of argument can be abstracted to any number of those arguments by making it variadic with triple-dot (...) syntax. Today, both of these features are permitted separately: you can define a generic function that takes a variable number of arguments, such as

func debugPrint<T>(_ items: T...) 
  where T: CustomDebugStringConvertible
{   
  for (item: T) in items {
    stdout.write(item.debugDescription)

DougGregor

Swift 5.5 proposals:

• SE-0296: Async/await
• SE-0297: Concurrency Interoperability with Objective-C
• SE-0298: Async/Await: Sequences
• SE-0300: Continuations for interfacing async tasks with synchronous code
• SE-0302: Sendable and @Sendable closures
• SE-0304: Structured concurrency
• SE-0306: Actors
• [SE-0310: Effectful read-only properties](https://github.com/apple/swift-evolution/bl

DougGregor

extension Collection {
  func parallelMap<T>(
    parallelism requestedParallelism: Int? = nil,
    _ transform: @escaping (Element) async throws -> T
  ) async throws -> [T] {
    let defaultParallelism = 2
    let parallelism = requestedParallelism ?? defaultParallelism

    let n = self.count
    if n == 0 {

DougGregor

Preventing Data Races in the Swift Concurrency Model

One of the goals of the concurrency effort is to prevent data races. This document describes the approach taken to preventing data races overall, by categorizing the sources of data races and describing how they are addressed with other proposals in the Swift Concurrency effort.

Data races

A data race occurs when two threads access the same memory concurrently and at least one of the accesses can change the value. Within the safe subset of Swift (e.g., ignoring the use of UnsafeMutablePointer and related types), the memory in question is always a stored property. There are several different categories of stored properties that need to be considered for data races:

• Global and static stored properties:

DougGregor

IsaacXen

WWDC                                2006  2007  2008  2009
2010 2011 2012 2013 2014 

brennanMKE

LLDB Custom Commands

[LLDB] can be customized with ~/.lldbinit to run commands and to load more commands from shell and python scripts. One option is [Chisel] which provides several commands which can be used to debug an software running in Xcode.

It is critical that LLDB can process the commands in ~/.lldbinit successfully as a failure can cause the debugger to fail or run in an undefined way. The configuration listed in this Gist prints a message at the start and end so that when the debugger is run it is clear if any errors are shown in the Xcode console they are related to LLDB.

ole

import UIKit

/// A validation rule for text input.
public enum TextValidationRule {
    /// Any input is valid, including an empty string.
    case noRestriction
    /// The input must not be empty.
    case nonEmpty
    /// The enitre input must match a regular expression. A matching substring is not enough.
    case regularExpression(NSRegularExpression)

marcrasi

Compile Time Constant Expressions for Swift

• Proposal: SE-NNNN
• Authors: Marc Rasi, Chris Lattner
• Review Manager: TBD
• Status: Awaiting implementation

Swift-evolution thread: https://forums.swift.org/t/pitch-compile-time-constant-expressions-for-swift/12879

Introduction