Swift JSON v0.3.0 released

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.


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