Swiftpack.co - Swift Packages by RougeWare

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Now, lazy containers automatically gain conformance to these protocols when their `Value` also conforms to them: - `Equatable` - `Hashable` - `Encodable` - `Decodable` This means that every `@Lazy`, `@ResettableLazy`, and `@FunctionalLazy` field is automatically and transparently made to conform to these just like if they were not lazy! > **Important**: In order to do this, of course, the value will have to be evaluated. That is, if your `@Lazy` `Hashable` field is not yet initialized when you want to get its hash value, then it's automatically initialized first. Thanks to [Gabe Shahbazian](https://github.com/gshahbazian) for [reporting this bug](https://github.com/RougeWare/Swift-Lazy-Patterns/issues/20). This seems to have been a symptom of a lower-level bug in Swift <5.3, where it would not properly wrap `@autoclosure` arguments for property wrappers. Sadly, the only "fix" I could find was to prevent the `@Lazy` property wrapper from being used in Swift <5.3. If you need to use Swift 5.2 or earlier, you can still use the old style: ```swift // In Swift 5.2.x and earlier let expensive = Lazy<Expensive> { ExpenseFactory.next() } // In Swift 5.3 and newer @Lazy var expensive = ExpenseFactory.next() ``` Because this causes anyone using `@Lazy` property wrappers in Swift <5.3 to see compiler errors where there were none previously, this is a Major version increment. - Split the license into two, one special for certain entities, and the other for everyone else - Upgraded the license for everyone else from BH-0-PD to BH-1-PS. This means that, if this license applies to you, then you must provide attribution when using this package, among other requirements and restrictions. --- ### Patch Changes ### - **3.1.2** - Added alternative dynamic library product - **3.1.1** - Updated header comment in `LazyContainers.swift` Thanks to [Brandon Starcheus](https://github.com/BStarcheus) for fixing this with #15. --- See [the release notes for 3.0.1](https://github.com/RougeWare/Swift-Lazy-Patterns/releases/tag/3.0.1) for important changes since 2.x and 1.x. Resolved some assumptions about Swift Package Manager and updated to yet another Swift 5.1 beta syntax. Important changes since 2.x are listed in the readme: https://github.com/RougeWare/Swift-Lazy-Patterns/commit/84c7de0730ff0a4331bb47435a582293a2dac4e4#diff-04c6e90faac2675aa89e2176d2eec7d8 Important changes since 1.x are listed here: https://github.com/RougeWare/Swift-Lazy-Patterns/releases/tag/2.0.0 **With the 3.0.0 release, this package will no longer be distributed as a binary.** Please consume this as a Swift Package and compile it as a part of your build process. # New Features # * Rebranded to **Lazy Containers**, since this repo focuses on providing containers that lazily hold values, but doesn't focus providing patterns for how to do this (although, it does provide the tools to do that). * You can now use `Lazy`, `ResettableLazy`, and `FunctionalLazy` as [property wrappers](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md)! * `FunctionalLazy` is now passed by value, rather than by reference. * You can still lazily initialize the value held within a `Lazy`, `ResettableLazy`, nor a `FunctionalLazy` in a non-mutating way, but you can no longer manually set it. This remains consistent with the goal of this repo (to provide a way to lazily initialize a value). In order to set a value-passed instance in a non-mutating way, see [Swift-Safe-Pointer](https://github.com/RougeWare/Swift-Safe-Pointer). * You can now create an instance of any lazy container with a value already initialized inside it. This is useful when you need a uniform API (for instance, when implementing a protocol that requires a `Lazy`), but require it to already hold a value up-front. * Added repo format which allows this to be a [Swift Package](https://github.com/apple/swift-package-manager). * Added unit tests to continue proving stability.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This first beta addresses some issues regarding the concept of a semantic version: ## Breaking changes ## - `PATCH` is now required (#5) - All non-build identifiers now reject leading zeroes (#14) - Removed support for Swift 4 (#17) - Enforced that a semantic version (excluding extensions) only increases normally (#25) ## Other changes ## - Updated license to BH-1-PS Opus 3 (#4) - Completed documentation (#6) - Fixed problems with the comparison operator (#7; #24) - Now supports iOS, tvOS, & watchOS (#20) - Added `Codable` support (#27) - Added support for fuzzy equality (#29) Finally, a real release! SemVer is now ready for Swift Package Manager

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. And We did it without breaking existing code! Woo! This change makes that protocol more generic, so it can be applied to sizes, rectangles, anything which conforms. By default now, all integer sizes and rectangles gain this behavior which was once available only to sizes. Part of this was removing the requirement for conforming types to also conform to `Size2D`, and creating a new conformance requirement: `CartesianMeasurable`. We then changed `Size2D` to require `CartesianMeasurable`, and that enabled this broadening. ## What's Changed * `2.12.0` * #66 Changed `Size2DCollection` to `Collection2D` * `2.12.1` * #67 Added `distance` * `2.12.2` * #68 Made (min/max)X(min/max)Y more useful **Full Changelog**: https://github.com/RougeWare/Swift-Rectangle-Tools/compare/2.11.0...2.12.2 `Rectangle`s and `TwoDimensional`s can now be scaled within another one! This is handy for when you need, for instance, a photo to be scaled down to fit in a chat message, or a wallpaper to be scaled up to fill a background. The following scaling methods and directions are supported, and tested with **648** test assertions to guarantee expected behavior: #### Methods #### - **Fit** - Ensure the whole object is visible without clipping within its parent - **Fill** - Ensure the whole parent is filled with this object, exceeding boundaries as necessary, but not scaling larger than needed - **Match height** - The object is scaled to match the height of its parent, exceeding horizontal boundaries as necessary - **Match width** - The object is scaled to match the width of its parent, exceeding vertical boundaries as necessary - **Stretch** - The object is made the same as its parent #### Directions - **Down** - The object will either remain the same size or reduce in size - **Up or down** - The object will increase or reduce in size as necessary It's clear that Apple is moving forward with SwiftUI as the future of all their platforms, so now this package treats it like that too. This update makes `SwiftUI.EdgeInsets` one of the `NativeEdgeInsets`. ### Patches ### - **2.10.1** - Addressed an oversight which prevented this from compiling for WatchOS (#63) This mainly adds `.zero` and `.one` to `DualTwoDimensional`, so any rectangle can be easily created so that all 4 of its constituent dimensions are `0` or `1`. I also bundled into this release a first-attempt at fixing #48. Not confident, since it feels like a real Apple-side bug, but I think this might at least improve some flows. - `union(with:)` - to create a new rectangle which is a union of two rectangles - `formUnion(with:)` - mutates a rectangle to also encompass another - `grandUnion()` - returns the smallest rectangle which encompasses all rectangles in a collection This allows you to initialize a rectangle by saying where its edges are, like this: ```swift .init( minX: 0, minY: 2, maxX: 4, maxY: 6 ) ``` ``` 6 ┢━━━━━━━┓ 5 ┃ ┃ 4 ┃ ┃ 3 ┃ ┃ 2 ┡━━━━━━━┛ 1 │ 0 ┼──────────── 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 ┼──────────── 1 │ 2 ┢━━━━━━━┓ 3 ┃ ┃ 4 ┃ ┃ 5 ┃ ┃ 6 ┡━━━━━━━┛ ``` This genericizes and extends types like `NSEdgeInsets`/`UIEdgeInsets`/`EdgeInsets` Added iOS support by conditionally compiling `Float80` only for non-Windows x86 systems, importing `CoreGraphics`, and updating [`MultiplicativeArithmetic`](https://github.com/RougeWare/Swift-MultiplicativeArithmetic/releases/tag/1.3.0) to 1.3.0. Yay easy support changes! `TwoDimensional` now has these: - `aspectRatio()` - Returns the ratio of the X measurement to the Y measurement - `greaterThanZero` - Returns a copy where - `minMeasurement` - Simply returns the lower of the two measurements - `maxMeasurement` - Simply returns the greater of the two measurements - `product` - Returns the result of multiplying the measurements together And `Size2D` has these: - `minSideLength` - Like `minMeasurement`, but never negative - `maxSideLength` - Like `maxMeasurement`, but never negative - `area` - Like `product`, but never negative Some of these are duplicated for different types of `Length` since each has its own requirements. The goal is to provide consistent functionality regardless. ### Now, all sizes and rectangles have the following computed properties on them! ### - `minX` - `midX` - `maxX` - `minY` - `midY` - `maxY` - `minXminY` - `minXmidY` - `minXmaxY` - `midXminY` - `midXmidY` / `center` - `midXmaxY` - `maxXminY` - `maxXmaxY` - `maxXmidY` ### And these rectangle-only functions: ### - `percent(alongX:)` - `percent(alongY:)` - `relativePoint(xPercent:yPercent:)` - `minX(yPercent:)` - `maxX(yPercent:)` - `minY(xPercent:)` - `maxY(xPercent:)` These are split into two separate sets of APIs, which I hope will work harmoniously: 1. Fetching a point within an **integer** rectangle by passing **some other floating-point type** percentages, which returns the rectangle's **integer** type 2. Fetching a point within a **floating-point** rectangle by passing **the rectangle's floating-point type** percentages, which returns the rectangle's **floating-point** type ### And this incidental new protocol: ### - `InitializableFromInteger` - `init(_:)` which takes any `BinaryInteger` This might someday find its way to a new package. ### Relevant tickets ### - #24 - #34 - #38

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. RectangleTools found a way to solve the same problem without a major version change, so this downgraded to the newer RectangleTools 2.10.1 This requirement is mostly done to make sure that the ecosystem remains harmonious; you can always import the latest versions of all packages into your project. This means we also require its platform versions and Swift tools version, bumping this repo to 2.0.0. Also took this opportunity to give this package a proper readme! 🥳 A simple Swift package - all it does is draw rectangles of solid colors as `NSImage`s and `UIImage`s.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This provides static info on whether that upper bound is inclusive. It will be`true` iff the upper bound of this protocol includes the element at its index, like `...b` and `a...b`. `false` indicates that the upper bound does not include that element, like `..<b` and `a..<b`. --- ### 1.2.1 ### This patch allows all ranges to specify whether their upper bound is inclusive; [in 1.2.0, `upperBoundIsInclusive` was only available on `RangeWithUpperBound`](https://github.com/RougeWare/Swift-Range-Tools/blob/1.2.0/Sources/RangeTools/RangeProtocol.swift#L62-L63). Even when an upper bound isn't explicitly specified, it's still good to acknowledge whether it's inclusive, so we know that things like `myArray = [0,1,2]` can return `[]` validly when accessed like `myArray[3...]`. We might imagine that, given a hypothetical `a..<` range, `myArray[3..<]` would not validly return `[]`: ```swift let myArray = [0, 1, 2] myArray[0...] == [0, 1, 2] myArray[1...] == [ 1, 2] myArray[2...] == [ 2] myArray[3...] == [ ] myArray[0..<] == [0, 1] myArray[1..<] == [ 1] myArray[2..<] == [ ] myArray[3..<] == invalid! ``` So, even if the range doesn't specify its upper bound, we can still gain useful knowledge by understanding whether the upper end of it is inclusive This adds some more protocols to improve generic usage of ranges: - `RangeWhichCanBeInitializedWithOnlyLowerBound`: Any range which can be initialized only with a lower bound, like `a...` - `RangeWhichCanBeInitializedWithOnlyUpperBound`: Any range which can be initialized only with an upper bound, like `..<b` or `...b` - `RangeWhichCanBeInitializedWithBothLowerAndUpperBounds`: Any range which can be initialized with both lower and upper bounds, like `a..<b` or `a...b` Kicking this off with a few protocols to help make it easier to use Ranges! See [the Readme](https://github.com/RougeWare/Swift-Range-Tools/blob/145a9e2d5ae5820054daefe0bf281d204c21da49/README.md) for more info

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. A new kind of safe pointer was added: `ObservableMutableSafePointer`! Like `MutableSafePointer`, this lets the pointer's creator receive a callback when it changes. In addition to that, anything else can also register to listen for changes! And of course, this is all done the Swift way, so you don't have to keep track of these; they'll automatically get destroyed when the pointer leaves scope. Additionally, I added these typealiases so you don't have to remember the exact order of these adjectives: - `MutableSafePointer`: - `SafeMutablePointer` - `ObservableMutableSafePointer`: - `MutableSafeObservablePointer` - `SafeObservableMutablePointer` - `MutableObservableSafePointer` - `ObservableSafeMutablePointer` - `SafeMutableObservablePointer` ### Patch Changes ### Here are the changes in the patch versions: - **2.1.3** - Made `ObserverIdentifier` `public` - **2.1.2** - Made the above-listed new typeliases `public` - **2.1.1** - Made `ObservableMutableSafePointer` mutable from a property wrapper Resolved some assumptions about Swift Package Manager and updated to yet another Swift 5.1 beta syntax. In version `1.0.0`, the key file was located at `./SafePointer (Swift Package)/Sources/SafePointer/SafePointer.swift`. Now, it is located at `./Sources/SafePointer/SafePointer.swift`. Because the location of the file in the repo changed entirely, the version number was changed to `2.0.0`, although **the API has not changed at all since `1.0.0`**. As long as you make your project point to `SafePointer.swift`, it will be precisely the same in `2.0.0` as it was in `1.0.0`. **With the `2.0.0` release, this package will no longer be distributed as a binary.** Please consume this as a Swift Package and compile it as a part of your build process. ### Patch Changes ### Here are the changes in the patch versions: - **2.0.1** - Fixed #4 # SafePointer # Lets you pass anything using reference semantics without the danger of unsafe pointers. Do note that this is more of a conceptual pointer; one which points to some instance. This acknowledges no concept of memory addresses nor traversing memory. For that, you can use Swift's built-in `UnsafePointer` and its sisters.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. RectangleTools found a way to solve the same problem without a major version change, so this downgraded to the newer RectangleTools 2.10.0 ### Patches ### - **2.1.1** - RectangleTools 2.10.1 (#11) This requirement is mostly done to make sure that the ecosystem remains harmonious; you can always import the latest versions of all packages into your project. This means we also require its platform versions and Swift tools version, bumping this repo to 2.0.0. Took this Major version bump as an opportunity to both clean up the API a touch, and also fix a bug with context scaling in AppKit (#4), and also made it easier to include as a package (#8) Turns out i just typed `throws` out of habit after having to write a `try`. Whoops! Now you can use this API without a `try` keyword if your artist doesn't throw any errors. --- ### Patch Changes ### - `1.1.1` (#4) - Better handling of AppKit context scale/PPI. It's not perfect, but it's better. Now, `drawNew` does a better job at considering the scale/PPI of the image you want to draw, via the context you passed Some drawing tools! Check out [the Readme](https://github.com/RougeWare/Swift-Drawing-Tools/blob/1.0.0/README.md) for what shipped first in this package 😄

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Added the ability to read the bundle ID with any of these: ```swift Introspection.Bundle.id Introspection.Bundle.id(of: .main) // Or any other Foundation.Bundle instance Introspection.bundleId Bundle.main.id // Or any other Foundation.Bundle instance ``` ## Also: ## - Also updated SemVer to `3.0.0-Beta.5` - Also resolved other packages - Support for iOS device info This update adds sugar for getting the name of a bundle: ```swift Introspection.appName // The name of your app, as read from its bundle info Introspection.Bundle.name(of: .main) // Same as previous Introspection.Bundle.name(of: Bundle(for: SomeClass.self)) // The name of the bundle `SomeClass` is in ``` # Introspection 1.0.0 # A Swift package which aides in checking information about the current app, system, & device. ## The app bundle ## This includes some sugar for reading your app bundle: ```swift import Introspection Introspection.appVersion // The semantic version of your app, as read from its bundle info, parsed into a `SemVer` value ``` This package also includes a generic version reader for any bundle: ```swift import Introspection Introspection.Bundle.version(of: Bundle(for: SomeClass.self)) ``` And makes general bundle access easier: ```swift import Introspection let accentColorName: String? = Introspection.Bundle["NSAccentColorName"] let supportedPlatforms: [String]? = Introspection.Bundle["CFBundleSupportedPlatforms"] ``` ## The device ## This also lets you check info about the current device: ```swift import Introspection Introspection.Device.modelType == .iPhone Introspection.Device.class == .laptop ``` --- ### Patches ### - **1.0.1** - Forgot to make some subscripts public - **1.0.2** - Fixed a bug with error-SemVer generation

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. `sqrt` and `pow` are like fancy multiplying right? Right. So now they're here! Turns out the standard libraries tend to include these already so We just had to thinly wrap them. Except `Decimal`; that had some ancient ObjC weirdness. Woo! Added iOS support by conditionally compiling `Float80` only for non-Windows x86 systems, and by importing `CoreGraphics`. Yay easy support changes! `Decimal` now conforms to `MultiplicativeArithmetic` by default The following types now conform to `MultiplicativeArithmetic`: - `CGFloat` - `Float32` - `Float64` - `Float80` - `Int` - `Int8` - `Int16` - `Int32` - `Int64` - `UInt` - `UInt8` - `UInt16` - `UInt32` - `UInt64` Just a couple protocols to say something can be multiplied

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Now, both `EssentiallyAString` and `SpecialString` conform to `Codable`, making it easy to encode and decode your special string, or anything else which is essentially just a string --- ### Patch Changes ### - **1.1.3** - Added a dynamic library product whose name is a valid bundle identifier - Deprecated previous dynamic library product because its name caused problems when submitting to the App Store - **1.1.2** - Added alternative dynamic library product - **1.1.1** - Added dual licenses - `SpecialString` - Leverage Swift's powerful type system to make sure no two kinds of string are mixed up - `EssentiallyAString` - The backbone of the handy ergonomics of `SpecialString` - Premade special strings - `UnsafeUserInput` - Unsafe user input. It must be sanitized before it can be safely used. - `SanitizedUserInput` - User input which has gone through some process and can now be deemed safe to use. - `Password` - A password. It must never be serialized as a plaintext string.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Added three new operators: - `-?` - If both have values, performs `left - right`. Otherwise, returns `nil` - `+?` - If both have values, performs `left + right`. Otherwise, returns `nil` - `=?` - If the right has a value, performs `left = right`. Otherwise, does nothing --- ### Patch Changes ### - **1.1.3** - Added a dynamic library product whose name is a valid bundle identifier - Deprecated previous dynamic library product because its name caused problems when submitting to the App Store - **1.1.2** - Added alternative dynamic library product - **1.1.1** - Added dual licenses Just `.unwrappedOrThrow()` for now 👍🏼

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. We already had `integers + 7`, now we also have `7 + integers`! `@ArrayBuilder` is a basic result builder which transforms all of its children into an array. This can be used to great effect when needing to use logic while building an array, like this: ``` self.tabsArray = Array { homeTab searchTab if !isGuestMode { profileTab } settingsTab } ``` [2.3.0](https://github.com/RougeWare/Swift-Collection-Tools/releases/tag/2.3.0) introduced some new `map` APIs which take a transformer function. Two of them were ambiguous in many circumstances without explicit type declaration, which doesn't work well in Swift. So, I removed the one that's only for lazy collections and made the one for all collections always-lazy. I have no idea why this isn't in the standard library nor Foundation, but I often find myself wanting to do something like this: ``` ["Vivien", "Marlon", "Kim", "Karl"].map(String.lowercased) ``` Now I can! With any collection type, into any collection type. This update adds these small tools: - `isNotEmpty` - Simply an inverse of `isEmpty`, for terse and clear code. Inlined so you never worry about this bloating your executable - `nonEmptyOrNil` - Iff the collection is empty, this returns nil, otherwise it returns the collection. Useful for leveraging APIs whose behavior changes based on a value's optionality, such as `guard` or `??` - `onlyFirst(_:)` - Returns only the first `k` values of the collection. This uses `dropLast(_:)` under the hood for performance. - `onlyLast(_:)` - Returns only the last `k` values of the collection. This uses `dropFirst(_:)` under the hood for performance. - `+` - Range-replaceable collections have this to concatenate two collections together. This lets you simply concatenate one element to the end of an existing range-replaceable collection. - `+=` - The same as `+`, but mutates the left-hand-side, rather than returning a new collection This allows you to lazily consume any sequence as a series of its ordered pairs These no longer return a generic collection, but instead always return the same kind of lazy version of the current collection. Also added variants to `everyPairWithoutDuplicates` which allow you to use them when the collection elements aren't `Equatable`! Added `withoutDuplicates()` to filter out duplicate elements Starting with something simple: `everyPair` and `CollectionWhichCanBeEmpty`

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Migrator uses semantic versions to help you migrate the data in your software. Simply define your migration approach as functions, save them in `Migrator` objects, and dump them in the `MigrationEngine`. When you're ready to go, all you have to do is call `performMigration` with the previous & new version of the software, and it'll take care of the rest. Migrations are performed in parallel in the background with updates published via a Combine `Publisher`, so you can present whatever UI you want while migration is underway. --- ### Patch Changes ### - `1.0.1` - Made `MigratorEngine.init()` `public` (#3)

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Big changes this time! - New `CombinedLoggable` and `CombinedLogMessage` to combine two messages in one log line - Added new log channel location: `.custom`, which takes one function that you can use to implement your own location - Replaced the confusing minimum log severity with a semantic `LogSeverityFilter` - Removed a bunch of odd log severity names. If you want these, feel free to implement them yourself - it's just a couple lines 😁 - Added `LoggableError` to aide in logging errors - It now depends on `FunctionTools` for the new custom log channel location --- #### Patch Changes #### - `0.5.1` - Bumped `LazyContainers` to `4.0.0` #16 - `0.5.2` - Changed `LazyContainers` URL to the current one #18 License is now split into two semantic licenses depending on the entity obtaining the license. --- ### Non-licensing patch changes ### - **0.4.4** - Added a dynamic library product whose name is a valid bundle identifier - Deprecated previous dynamic library product because its name caused problems when submitting to the App Store - **0.4.3** - Added alternative dynamic library product Logging errors works much better now! Not only does `log(error:)` have a special variant for taking an error, but there's also a new log function `log(errorIfThrows:backup:)`, which gracefully handles errors, both with a log message iff the given call throws, and with a backup if it's needed: ```swift myVeryGoodFunction(count: log(errorIfThrows: try readCountFromDisk(), backup: 0)) ``` That's one line to both handle an error and provide a backup without ignoring the error! Here's what that same operation would look like without this: ```swift do { myVeryGoodFunction(count: try readCountFromDisk()) } catch { log(error: error) myVeryGoodFunction(count: 0) } ``` And sure, you could use `try?` and `??`, but then you ignore the error entirely. Personally, I see myself using this log function quite often 😄 --- ### Additional Fixes ### This release also fixes #4, where the file/line/function were not actually being logged. Whoops! Before: ```swift log(severity: .critical, loggable: "Important message") log(severity: .trace, any: notableObject) ``` Now: ```swift log(severity: .critical, "Important message") log(severity: .trace, notableObject) ``` --- ### Patch Changes ### - `0.2.1` - Added GitHub Actions, only imported CoreGraphics on non-desktop Apple platforms A simple logging framework for Swift

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This release brings three new function generators: - `echo(_:)` - A new `echo` function which creates and returns a function which only ever returns the value you gave the `echo` function - `constant(_:)` - Two functions which always return the same value: one just like the above `echo` function (purely alias for clarity), and one which creates a non-transformer which ignores its input always returns the same value - `!` - Creates a function which simply inverts the output of the function after the exclamation point See the Readme for examples! --- ### Patch Changes ### - **1.2.4** - #13: Made the `curry` function `public` - **1.2.3** - Added a dynamic library product whose name is a valid bundle identifier - Deprecated previous dynamic library product because its name caused problems when submitting to the App Store - **1.2.2** - Added alternative dynamic library product - **1.2.1** - Added dual licenses Like it says on the tin, these just echo what they're given. The first version simply returns the value it's given. This is useful for reusing the input of higher-order functions: ```swift let withoutNils = arrayOfOptionals.compactMap(echo) ``` The second version is useful for flattening collections of generators: ```swift let values = generators.map(echo) ``` Just a few things that I've written and re-written over and over again over several projects, just to make functions a little nicer 🙂

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Finally, you can use this package to safely mutate collections, as well as accessing them safely as always! All existing accessors now have mutating companions: - `[orNil:]` taking an index can now set that index, remove that element by setting it to `nil`, or do nothing if that index lies outside the collection - `[orNil:]` taking an index range can now set that range to the contents of a subsequence, remove the elements at that range by setting it to `nil`, or do nothing if that index range goes beyond the collection boundaries - `[clamping:]` taking an index can now set that index, remove that element by setting it to `nil`, or set the closest slot if the index lies outside the collection, or do nothing if the collection is empty ### 2.2.1 ### This patch fixes a crash when using this package to address strings and other collections which don't allow you to get an index if it's outside the collection ### 2.2.2 ### This patch adds a license to the codebase ## What's New ## In 1.2.0, the safe range subscripts were introduced. However, at the edges of collections, their behavior was inconsistent with Swift's built-in range subscripts - they would return `nil` instead of an empty collection. Now, these have been made the same, returning an empty subsequence, where before this package's versions would return `nil`: - `collection[collection.endIndex...] == collection[orNil: collection.endIndex...]` - `collection[..<collection.startIndex] == collection[orNil: ..<collection.startIndex]` --- ## Why not `3.0.0`? ## > This change breaks the contract of the API, shouldn't it be a MAJOR version bump? While that's true, it does so in a backward-compatible way. Any code which was using the `2.0.0` version of these APIs will still work: if it was using a range that `2.0.0` considered valid, it'll still get the same result; if it was using a clearly invalid range, it'll still get `nil`; the only difference is that if it was using one of the above example edge ranges, it'll now get a non-nil result. Thanks to how Swift thinks about optional values, this will be gracefully handled by any code that does this. Because of this grace, a MAJOR version bump is not necessary. Yay! --- ## Patch Changes ## - `2.1.1` - Fixed typo in comment, improved performance of `[orNil: PartialRangeFrom<Index>]` # What's New # Now you can safely subscript a collection using ranges, without requiring that the collection's indices are `Strideable` by `SignedInteger`s. This also comes with improvements to these subscripts to make them all O(1)! To achieve this, now collections with non-contiguous indices (like `Set`s) might not behave the same as before. Because of that, this is technically incompatible with the old version so, it's `2.0.0` instead of `1.3.0`. # What's Old # `[safe:]` has been removed, for both improved clarity and reduced tech debt. Instead, use `[orNil:]` for the same behavior, or `[clamping:]` if that's the best safe behavior for you. # What's New # You can now use these kinds of ranges to safely access any elements in any random-access collection whose indices are strideable (Most Foundation collections are this way): - `Range` - `ClosedRange` - `PartialRangeFrom` - `PartialRangeUpTo` - `PartialRangeUpThrough` # What's Old # I chose to deprecate `[safe:]`. It was solely an alias to `[orNil:]`, and its name describes the whole point of every API this package, thus making it nondescript to the point of reducing clarity. Also, it would have required each `[orNil:]` API to be duplicated to a `[safe:]` one. Removing it increases clarity and decreases tech debt. **It will be removed eventually, in SafeCollectionAccess 2.0.0**. Like `[orNil:]`, this won't crash when you access indices outside the collection. However, unlike `[orNil:]`, instead of returning `nil` for those, `[clamping:]` will return the element at the closest extreme. If the collection is empty, then there is no such extreme, and so it will return `nil`. Access any index in a `RandomAccessCollection` (including `Array`s) but it won't crash if you're out of bounds! --- **Patch changes:** * 1.0.1 * Added the subscript labels to the examples in the readme. Can't believe I forgot that 😅

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This repo now works as a Swift Package 🥳 I forgot I could do these XD

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This introduces a `.reduce(_:)` function to sequences whose elements conform to `AdditiveArithmetic` which assumes you're reducing into `.zero`: ```swift // Before bunchaNumbers.reduce(into: 0) { $0 = max($0, $1) } // After bunchaNumbers.reduce { $0 = max($0, $1) } ``` This also adds a convenience function `.sum()`, build on this new reducer: ```swift // Before bunchaNumbers.reduce(into: 0, +=) // After bunchaNumbers.sum() ``` #### Patch Notes * `1.3.0` * #12: Added `.reduce` which assumes reducing into 0 when elements are additive **Full Changelog**: https://github.com/RougeWare/Swift-Basic-Math-Tools/compare/1.2.1...1.3.0 So you want your value to be within a particular range, but instead of clamping when it gets outside that range, you want it to repeat back to the beginning of the range?  Now that's as simple as calling `.wrapped(within:)` on any number! ```swift value.wrapped(within: range) ``` This loops the number within the range, like this:  Here's a code example of how this works: ```swift print(0.wrapped(within: 3..<6)) // 3 print(1.wrapped(within: 3..<6)) // 4 print(2.wrapped(within: 3..<6)) // 5 print(3.wrapped(within: 3..<6)) // 3 print(4.wrapped(within: 3..<6)) // 4 print(5.wrapped(within: 3..<6)) // 5 print(6.wrapped(within: 3..<6)) // 3 print(7.wrapped(within: 3..<6)) // 4 print(8.wrapped(within: 3..<6)) // 5 ``` --- ### Patches - `1.2.1` • #10 • Fixed compiler error when archiving This update introduces some simple clamp functions! These make it easy to clamp a value between two others. Like Swift's `min` and `max`, these work for any `Comparable` type. Whichever you use simply depends on your preference or needs; they all act identically: ```swift print(clamp(min: 2, value: 0, max: 7)) // Prints 2 print(clamp(min: 2, value: 5, max: 7)) // Prints 5 print(clamp(min: 2, value: 99, max: 7)) // Prints 7 print( 0.clamping(min: 2, max: 7)) // Prints 2 print( 5.clamping(min: 2, max: 7)) // Prints 5 print(99.clamping(min: 2, max: 7)) // Prints 7 print( 0.clamping(within: 2...7)) // Prints 2 print( 5.clamping(within: 2...7)) // Prints 5 print(99.clamping(within: 2...7)) // Prints 7 ``` ### Patch Updates ### - **1.1.1** - Added support for non-x86_64 platforms Kicking this off with one of my favorite little tools - tolerable equality. Basically gets rid of silly little IEEE FP rounding errors, and helps with doing math with big numbers. Hope it helps you too!

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This version adds a `TODO` function which returns the context's expected type (#5) This is for when you use it in a place where `Never` is inappropriate, but you still aren't done writing an implementation, like this: ```swift func magic() -> String { return TODO() } ``` Before this version, the above code sample wouldn't compile, complaining that: ```plain Cannot convert return expression of type 'Never' to return type 'String' ``` Now, it compiles just fine, and crashes as expected This `TODO` pattern lets you compile functions which are incomplete, whose bodies you intend to write later but don't need right now. This lets you run your app and test features which you know don't touch the not-yet-written code. --- ### Patch Changes ### - **1.0.3** - Added a dynamic library product whose name is a valid bundle identifier - Deprecated previous dynamic library product because its name caused problems when submitting to the App Store - **1.0.2** - Added alternative dynamic library product - **1.0.1** - Updated licensing

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. This even introduces some functionality that Swift `String`s don't have! ```swift var someString = "Hello, World!" someString[1...4] // "ello" someString[7..<12] = "Mars" // "Hello, Mars!" someString[orNil: ...4] = "Howdy" // "Howdy, Mars!" someString[orNil: 999...] = "Boundaries" // "Howdy, Mars!" ``` ### Licensing ### This also changes the license so it's explicitly [BH-1-PS](https://github.com/RougeWare/Swift-String-Integer-Access/blob/2.1.0/LICENSE.txt). More integer accessors, these without crashes! Drawing from [Swift Safe Collection Access](https://github.com/RougeWare/Swift-Safe-Collection-Access), you can now access strings with `Int`s, and if you pass an invalid value to these new `orNil` subscripts and functions, they will return `nil` instead of crashing! ```swift import SafeStringIntegerAccess let someString = "Hello, World!" someString[orNil: 3..<5] == "lo" someString[orNil: 3..<5] == someString[3..<5] someString[orNil: 42..<99] == nil someString[orNil: -10 ..< -5] == nil ``` **To take advantage of this new behavior, `import SafeStringIntegerAccess`.** This will give the old behavior as well. If you just want the old behavior, `import StringIntegerAccess` instead. --- Additionally, the `NSRange` subscript introduced in `1.2.0` now returns a `Substring` rather than an `Optional<Substring>`, crashing if the given range is invalid. For the non-crashing, optional-return behavior, pass your `NSRange` to the `[orNil:]` subscript. In doing this update, the `NSRange` subscripts were updated to fix a bug with the way it processes strings with higher-plane Unicode characters and grapheme clusters. Allows you to just pass a `NSRange` to a `String`'s subscript. Great for working with things like `NSRegularExpression`! Now supports all types conforming to `StringProtocol`, and all range subscripts Some basic integer-based string subscripts. If I continue to hit similar frustrating barriers, I'll add more to address those.