Skip to content

Instantly share code, notes, and snippets.

Matthew Johnson anandabits

Block or report user

Report or block anandabits

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@anandabits
anandabits / Catamorphism.swift
Created Jun 27, 2019
An implementation of the catamorphism recursion scheme in Swift
View Catamorphism.swift
// 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
anandabits / Safer SwiftUI Environment.md
Created Jun 16, 2019
Towards a safer SwiftUI environment
View Safer SwiftUI Environment.md

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
anandabits / Identifiable.md
Last active Jul 2, 2019
Identifiable proposal
View Identifiable.md

Identifiable

Introduction

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

@anandabits
anandabits / Identifiable.swift
Last active Jul 2, 2019
Implementation of the Swift Identifiable protocol
View Identifiable.swift
/// 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
anandabits / enhanced-variadic-parameters.md
Last active Apr 11, 2019
Enhanced Variadic Parameters
View enhanced-variadic-parameters.md

Enhanced Variadic Parameters

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
anandabits / explicit-memberwise-initializers.md
Last active Apr 10, 2019
Explicit Memberwise Initializers
View explicit-memberwise-initializers.md

Explicit Memberwise Initialization

Introduction

View ValueSemantics.md
@anandabits
anandabits / Monoid.swift
Created Jan 8, 2019
Exploring the design space for the Monoid abstraction in Swift
View Monoid.swift
/*
This gist contains an analysis of the design space for abstractions in a type system like Swift's.
It focuses on Monoid as an example but the same set of tradeoffs apply to any abstraction.
As such, it focuses on a single abstraction and does not explore issues that arise when designing
an abstraction hierarchy in depth.
The matrix below describes some of the design important design tradeoffs for various approaches including:
- OO style protocols such as `Monoid { var identity: Self ... }
(Haskell also adopts this approach for many abstractions, including for Monoid)
- ML signature style static protocols with empty enum conformances analagous with ML structures
@anandabits
anandabits / ConstraintAbstraction.swift
Created Feb 12, 2018
A (non-working) experiment in abstracting over constraints in Swift
View ConstraintAbstraction.swift
// NOTE: This is an experiement that does not actually work (in the 2/8/18 nightly toolchain).
// The idea is to use Swift's constraint inference to be able to abstract an arbitrary set of constraints.
/// An empty enum serving as an example of the general case of
/// representing a set of constraints that relate multiple types.
/// This specific example provides the constraint that both types are sequences and they have the same Element type.
enum Parallel<S1: Sequence, S2: Sequence> where S1.Element == S2.Element {
typealias First = S1
typealias Second = S2
}
@anandabits
anandabits / ClosedProtocol.swift
Created Feb 11, 2018
Emulating closed protocols in Swift
View ClosedProtocol.swift
// This example shows how closed protocols can be emulated in Swift today.
// The technique leverages Swift's support for public (but not open) classes.
// First, it's worth observing that there is an almost trivial technique that can be used when
// it is possible to specify a (possibly abstract) superclass for all conforiming types.
// Simply declare a public (not open) base class and a protocol with a Self inheritance constraint.
// Swift does not support open subclasses of a public superclass so no classes outside the module
// will be able to meet the self inheritance constraint.
public class FooBase {}
public protocol Foo where Self: FooBase {}
You can’t perform that action at this time.