This proposal requests the inclusion of Swift System in official Swift toolchain releases for all supported platforms. Swift System provides idiomatic Swift interfaces to system calls and low-level currency types such as FilePath, serving as a foundational building block for the Swift ecosystem.
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.
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.
This is now hosted in the repo: https://github.com/apple/swift-experimental-string-processing/blob/main/Documentation/BigPicture.md
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.
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.
.start and .end, now all OffsetBounds are built from .first and .last.
.last + 1 representing the end is mostly only relevant to documentation.OffsetBound abstraction and terminology from indices..insert(at:), .remove(at:), etc.,
| struct StringFormatters { | |
| var text = "Hello, World!" | |
| } | |
| /* | |
| This is the master template for fprintf format string functionality. | |
| For development purposes only | |
| ``` |
| /// | |
| /// Collection Consumers | |
| /// | |
| protocol CollectionConsumer { | |
| associatedtype Element | |
| func consumeFront<C: Collection>(_ c: C) -> C.Index? where C.Element == Element | |
| } |
| // The below will be a customization point on Collection. For the purposes of | |
| // this gist, we'll fake/approximate it with static overloads | |
| extension Collection { | |
| /// Returns an index `distance` positions prior to `i` if it exists. | |
| /// | |
| /// Other methods such as `index(_:offetBy:)` must not be passed a negative | |
| /// offset if the collection is bidirectional. This method will perform a | |
| /// negative offset even if the collection is not bidirectional, by using a | |
| /// less efficient means. `BidirectionalCollection` customizes this with a |
| // TODO: doc | |
| public struct OffsetBound { | |
| internal enum Kind { | |
| case fromStart(Int) | |
| case fromEnd(Int) | |
| } | |
| internal var kind: Kind | |
| internal init(fromStart: Int) { | |
| self.kind = .fromStart(fromStart) |