1.2.0

This release adds an initializer JSON.Node.init(parsingFragment:) that accepts any JSON value (including leaf nodes) instead of just Arrays and Objects.

Full Changelog: 1.1.2...1.2.0

1.1.2

This release upgrades the package’s swift-grammar dependency.

For SwiftPM users, this has the practical effect of freeing the package of a transitive swift-atomics dependency, although the actual library targets in this package never even depended on swift-atomics in the first place, and that repository would only be cloned due to SwiftPM’s strange insistence on speculatively downloading all GitHub dependencies discoverable from the root manifest.

Full Changelog: 1.1.1...1.1.2

1.1.1

This release drops the package’s swift-testing dependency (as Testing now ships with the toolchain), and in turn frees it of its transitive swift-syntax dependency. It contains no functional changes to the library, but restores the ability to build the package as a whole (including tests) for CI purposes using a Swift 6 toolchain.

Full Changelog: 1.1.0...1.1.1

1.1.0

This release adds JSONEncodable conformances for Array and ArraySlice.

1.0.1

This release updates the swift-grammar (0.4) and swift-testing (0.7) dependencies to their next minors, to unblock anyone currently stuck in dependency hell due to one or both of those packages.

1.0.0

Swift JSON is a Foundation-free JSON parser and encoder written in pure Swift. It is designed to be performant, expressive, and speedy to compile.

Swift JSON builds on linux and macOS. As of version 1.0.0, it requires Swift 5.10 or newer.

You can get started with Swift JSON by reading its documentation, or by following the tutorial.

0.3.0

swift-json v0.3.0 is finally here!

obsoleting json dictionary representations

version 0.2 of swift-json modeled objects (things written in curly braces {}) as dictionaries of String keys and JSON values:

case array([Self])
case object([String: Self])

this is the most obvious representation for a JSON value, it’s convenient for many use cases, and it dovetails nicely with the JSON.array(_:) enumeration case. however, this representation also comes with some functional and performance issues, so we have replaced this representation with a array-based [(key:String, value:JSON)] representation. this matches APIs vended by Dictionary itself.

case object([(key:String, value:Self)])

to convert an object to a Dictionary, use one of the as(_:uniquingKeysWith:) methods on JSON.

ergonomics for high-performance decoding APIs

previously, users of swift-json had to choose between a slow but ergonomic Decodable-based API, and a fast but extremely verbose direct decoding API. swift-json v0.3 comes with a much more ergonomic API for high-performance decoding.

to decode objects, you can now use the LintingDictionary abstraction, and to decode arrays, you can now use swift-json’s Array extensions. in addition to being faster, using these decoding interfaces also gives better error diagnostics when decoding fails.

for an example of how to use LintingDictionary, see its associated snippet.

RawRepresentable convenience APIs

swift-json v0.3 comes with a handful of new convenience APIs for decoding RawRepresentable types directly from JSON messages:

func `as`<StringCoded>(cases: StringCoded.Type) throws -> StringCoded

func `as`<CharacterCoded>(cases: CharacterCoded.Type) throws -> CharacterCoded

func `as`<ScalarCoded>(cases: ScalarCoded.Type) throws -> ScalarCoded

func `as`<IntegerCoded>(cases: IntegerCoded.Type) throws -> IntegerCoded

func `as`<UnsignedIntegerCoded>(cases: UnsignedIntegerCoded.Type) throws -> UnsignedIntegerCoded

avoid working with swift-grammar directly

version 0.2 of swift-json re-exported Grammar’s entire API, and expected users to invoke swift-grammar parsing rules directly. this was done to reduce the amount of “magic” in the parser, and guide users towards the lowest-overhead parsing configurations needed for their use case, which was important back when swift-json was a closed-source library primarily used for fintech applications. however it also made for a very complex API that was hard to learn if you were not already familiar with how swift-grammar works.

version 0.3 of swift-json now comes with a simplified init(parsing:) initializer, which takes UTF-8-encoded input, and just “does the right thing” by default.

ExpressibleBy_Literal conformances

the JSON type now conforms to ExpressibleByArrayLiteral,ExpressibleByBooleanLiteral, ExpressibleByDictionaryLiteral, ExpressibleByExtendedGraphemeClusterLiteral, ExpressibleByStringLiteral, and ExpressibleByUnicodeScalarLiteral.

platform and toolchain support

swift-json supports swift 5.3 ... 5.8 nightly, and has official CI coverage for linux, macOS, iOS, watchOS, tvOS, and windows.

swift-json has a fully-green build matrix on the swift package index.

documentation

we have expanded swift-json’s documentation, and published it on swiftinit.

0.2.2

this release contains backported fixes to get this package compiling again with the swift 5.6 toolchain in the wake of SE-0335 being dropped from swift 5.6. it also specifies the swift-grammar dependency version more precisely.

0.2.1

• fixes some symlink-related problems with editable SPM packages.
• adds a more helpful compiler diagnostic when using the deprecated JSON.IntegerOverflowError.type property.

0.2.0

json
0.2.0

hi all, about a month ago, we released the experimental swift-json v0.1.0.

swift-json up to v0.1.6 only compiles on the swift 5.6 nightlies, and contains executable test targets that only compile on linux, which meant the package as a whole only compiles on a nightly toolchain on a linux platform.

as i’m sure many will agree, this is quite silly, so we’ve made it a goal to support at least three minor swift releases, as well as macOS, iOS, watchOS, and tvOS.

as part of the 0.2.0 release, we’re pleased to announce that swift-json now supports all the swift package index targets, going all the way back to swift 5.3.

look at all that green!

as the project has matured, i’ve also set up a CI pipeline to test a number of platform × toolchain configurations directly in GitHub Actions.

we are now explicitly testing the following platform × toolchain combinations:

• build-macos (macos-11)
• build-macos (macos-10.15)
• build-linux (ubuntu-20.04, 5.5.3)
• build-linux (ubuntu-20.04, 5.4.3)
• build-linux (ubuntu-20.04, 5.3.3)
• build-linux (ubuntu-18.04, 5.5.3)
• build-linux (ubuntu-18.04, 5.4.3)
  build-linux (ubuntu-18.04, 5.3.3)

(Windows is on the way too!)