anandabits

Explicit Memberwise Initialization

• Proposal: SE-NNNN
• Authors: Matthew Johnson
• Review Manager: TBD
• Status: Awaiting implementation
• Previous Proposal: SE-0018

Introduction

anandabits

Enhanced Variadic Parameters

• Proposal: SE-NNNN
• Authors: Matthew Johnson
• Review Manager: TBD
• Status: Awaiting implementation

Introduction

This proposal enhances variadic parameters by introducing support for user-defined types, labeled variadic parameters, and a choice at the call site of whether to provide a variadic argument list or a collection value.

anandabits

/// A class of types whose instances hold the value of an entity with stable identity.
protocol Identifiable {

    /// A type representing the stable identity of the entity associated with `self`.
    associatedtype ID: Hashable

    /// The stable identity of the entity associated with `self`.
    var id: ID { get }
}

anandabits

Identifiable

• Proposal: SE-NNNN
• Authors: Matthew Johnson, Kyle Macomber
• Review Manager: TBD
• Status: Awaiting implementation

Introduction

SwiftUI introduces an Identifiable protocol. This concept is broadly useful—

anandabits

Towards a safer SwiftUI environment

Swift UI's @EnvironmentObject is currently prone to runtime errors. If a view uses an environment object of a type that was not injected using environmentObject a fatalError occurs. This document sketches a design that would support compile-time checking of environment object usage. It requires a few language enhancements.

Tuple intersection types

Swift's protocol composition types such as Protocol1 & Protocol2 are a form of intersection types. Other forms of intersection types are possible. For example, Flow has object intersection types. Tuple intersection types for Swift would be very similar to these.

Below, you can see the examples in the Flow documentation converted to Swift's tuples:

anandabits

// NOTE: This code was written when I first figured out how to encode HKT in Swift.
//       There is a lot that can be improved and I would write it somewhat differently today.

// This example shows how higher-kinded types can be emulated in Swift today.
// It acheives correct typing at the cost of some boilerplate, manual lifting and an existential representation.
// The technique below was directly inspired by the paper Lightweight Higher-Kinded Polymorphism
// by Jeremy Yallop and Leo White found at http://ocamllabs.io/higher/lightweight-higher-kinded-polymorphism.pdf

/// `ConstructorTag` represents a type constructor.
/// `Argument` represents an argument to the type constructor.

anandabits

/// - returns: `true` when dynamic type is `Equatable` and `==` returns `true`, otherwise `false`.
func areEquatablyEqual(_ lhs: Any, _ rhs: Any) -> Bool {
    func receiveLHS<LHS>(_ typedLHS: LHS) -> Bool {
        guard
            let rhsAsLHS = rhs as? LHS
            else { return false }
        return areEquatablyEqual(typedLHS, rhsAsLHS)
    }
    return _openExistential(lhs, do: receiveLHS)
}

anandabits

func testIsBidirectional() {
    func assert<C: Collection>(_ collection: C, isBidirectional: Bool) {
        XCTAssertEqual(collection.isBidirectional, isBidirectional)
    }

    assert([1, 2, 3], isBidirectional: true)
    assert(Set([1, 2, 3]), isBidirectional: false)
}

extension Collection {

anandabits

// NOTE: behavior is exhibited in the 14.1 simulator and previews in Xcode 12.1

struct OverlayRowClipping: View {
    let rowData = (1...50).map { "row \($0)" }

    @State var alertIsOpen = false

    var body: some View {
        List {
            Section(header: Text("The Header")) {