tayloraswift

Improved Swift pointers

• Proposal: SE-1989
• Authors: Kelvin Ma
• Review Manager: TBD
• Status: Awaiting review

Introduction

Swift currently offers two sets of pointer types — singular pointers such as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutableBufferPointer. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement Collection conformance, while singular pointers do not.

tayloraswift

More improved Swift pointers

• Proposal: SE-1989 Deluxe
• Authors: Kelvin Ma
• Review Manager: TBD
• Status: Awaiting review

Introduction

Swift’s pointer types are an important interface for low-level memory manipulation, but the current API design is not very consistent, or convenient. Many memory methods demand a capacity: or count: argument, forcing the user to manually track the size of the memory block, even though most of the time this is either unnecessary, or redundant as buffer pointers track this information natively. In some places, poor naming choices and overengineered function signatures compromise memory safety by leading users to believe that they have allocated or freed memory when in fact, they have not.

tayloraswift

// whether or not the string conversions live in the main definition depends on whether
// or not the strings are used for debugging/UI purposes, or have an actual internal role 
// in the program
enum CasualAnswer
{
    case noWay, 
         yeahSure

    // Supported conversions from: Bool
    init(_ value:Bool) 

tayloraswift

enum Math<F> where F:FloatingPoint
{
    typealias V2 = (x:F, y:F)
    typealias V3 = (x:F, y:F, z:F)

    @inline(__always)
    static
    func add(_ v1:V3, _ v2:V3) -> V3
    {
        return (v1.x + v2.x, v1.y + v2.y, v1.z + v2.z)

tayloraswift

Improved pointers

• Proposal: SE-0184
• Author: Kelvin Ma (“Taylor Swift”)
• Review Manager: TBD
• Status: Awaiting review

Introduction

Swift’s pointer types are an important interface for low-level memory manipulation, but the current API design is not very consistent, complete, or convenient. Many memory methods demand a capacity: or count: argument, forcing the user to manually track the size of the memory block, even though most of the time this is either unnecessary, or redundant as buffer pointers track this information natively. In some places, poor naming choices and overengineered function signatures compromise memory safety by leading users to believe that they have allocated or freed memory when in fact, they have not.

tayloraswift

struct QueueCore<Element>
{
    // capacity always power of 2
    private 
    var buffer:UnsafeMutableBufferPointer<Element> = 
            UnsafeMutableBufferPointer<Element>(start: nil, count: 0), 
        zero:Int = 0
    
    public private(set) 
    var count:Int = 0 

tayloraswift

struct UnsafeBalancedTree<Element>:Sequence
{
    fileprivate
    struct NodeCore
    {
        enum Color
        {
            case red, black
        }

tayloraswift

import func Glibc.asin
import func Glibc.acos
import func Glibc.atan2

protocol RandomBinaryGenerator
{
    associatedtype RandomNumber where RandomNumber:UnsignedInteger,
                                      RandomNumber:FixedWidthInteger

    mutating func generate() -> RandomNumber

tayloraswift

Integer-convertible character literals

• Proposal: SE-0240
• Authors: Kelvin Ma (@taylorswift), Chris Lattner (@Chris_Lattner3), John Holdsworth (@johnno1962)
• Review manager:
• Status: Awaiting review
• Implementation (WIP): unicodeintegerliterals
• Threads: 1

Introduction

tayloraswift

protocol Convolvable 
{
    static 
    func convolve(_ a:Self, _ b:Self) -> Self
    
    static 
    func generate() -> Self
}

extension Int:Convolvable