milseman

///
/// Collection Consumers
///

protocol CollectionConsumer {
  associatedtype Element
  func consumeFront<C: Collection>(_ c: C) -> C.Index? where C.Element == Element
}

milseman

struct StringFormatters {
    var text = "Hello, World!"
}

/*

This is the master template for fprintf format string functionality.
For development purposes only

```

milseman

Changes in v2

• Removed .start and .end, now all OffsetBounds are built from .first and .last.
  • Simplifies usage and learnability. .last + 1 representing the end is mostly only relevant to documentation.
  • Better delineates OffsetBound abstraction and terminology from indices.
• Added RangeReplaceableCollection convenience overloads, as well as subscript setters.
  • .insert(at:), .remove(at:), etc.,

milseman

FilePath Syntactic Operations

Introduction

FilePath appeared in System 0.0.1 with a minimal API. This proposal adds API for syntactic operations, which are performed on the structure of the path and thus do not consult with the file system or make any system calls. These include inspecting the structure of paths, modifying paths, and accessing individual components.

Additionally, this proposal greatly expands Windows support and enables writing platform-agnostic path manipulation code.

Future Work: Operations that consult the file system, e.g. resolving symlinks.

milseman

FilePath Syntactic Operations

• Authors: Michael Ilseman, Saleem Abdulrasool
• Implementation: PR-14
• Previous version: version 1, changes

Introduction

FilePath appeared in System 0.0.1 with a minimal API. This proposal adds API for syntactic operations, which are performed on the structure of the path and thus do not consult with the file system or make any system calls. These include inspecting the structure of paths, modifying paths, and accessing individual components.

milseman

This is now hosted in the repo: https://github.com/apple/swift-experimental-string-processing/blob/main/Documentation/BigPicture.md

milseman

This is a pitch for some low-level Unicode operations to enable libraries to implement their own String-like functionality and types. The purpose of this API is to present low-level core components out of which libraries can make types and higher-level API (i.e. tools for tool-makers).

I'm interested in hearing about capabilities that libraries may need and getting design feedback.

Introduction

String performs many Unicode operations using a mix of internal and publicly available functionality in the stdlib. The stdlib provides some limited general-purpose Unicode API, though this is a very dusty corner of the stdlib. We want to enable libraries to vend their own String-like types and functionality.