Something like https://github.com/Zewo/JSON/blob/master/Source/JSON.swift

When calling jsonFromData with an array of UTF-16-encoded bytes, Jay throws unimplemented.

The RFC recommends to determine the encoding by looking at the initial bytes (section 3).

I don't really want UTF-16, but if the API offers (only) a raw bytes interface, I would expect it to take any encoding like JSONSerialization does.

JSON comments are a thing apparently. Add support for ignoring them during parsing.

@tannernelson can you please provide specific rules for where and when they can appear?

Use Vapor 1.0.3 contains Jay. Xcode 8.0.

.Package(url: "https://github.com/DanToml/Jay.git", majorVersion: 1)

func dictionaryToJayType(_ maybeDictionary: Any) throws -> JSON? {

    let mirror = Mirror(reflecting: maybeDictionary)
    let childrenValues = mirror.children.map { $0.value }

    var obj = [String: JSON]()
    for i in childrenValues {

        let childMirror = Mirror(reflecting: i)
        let children = childMirror.children
        if childMirror.displayStyle == .tuple && children.count == 2 {
            let it = children.makeIterator()
            let maybeKey = it.next()!.value
            guard let key = maybeKey as? String else {
                throw JayError.keyIsNotString(maybeKey)
            }
            let value = it.next()!.value
            obj[key] = try self.toJayType(value) // Int 1 -> .boolean(true)
        } else {
            throw JayError.unsupportedType(childMirror)
        }
    }
    return .object(obj)
}

Interesting approach with Mirrors: https://github.com/IBM-Swift/SwiftyJSON/blob/master/Source/LclJSONSerialization.swift
Or even better here: stencilproject/Stencil@070a82c

• http://tools.ietf.org/html/rfc7159
• add option to accept fragments, but don't by default (will require changes in the way we ensure reading isn't finished)

In some cases, I could see a use for having source maps for parsed JSON documents. For example, the character positions of parse JSON elements.

What do you think about this?

An example use-case could be for using JSON data used in tests and providing the exact location of a failure in a test.

• Example: https://github.com/uri-templates/uritemplate-test/blob/fdd5d611a849b922c2ff40fc3997fd265dd14c02/spec-examples-by-section.json#L213

The API that I consume (sinatra app) has numbers with exponent like this one: 6.8e-05. I don't think this is required by the current RFC4627 spec but I think this will make Jay (and Vapor) more compatible with other API services in the wild.

// this will fail
let data = "{ \"number\" : 6.8e-05 }".chars()
_ = try Jay().jsonFromData(data)

I can confirm that JS console and JSONSerialization support it.

I cannot parse a JSON object which has an integer value bigger than Int.max.

The error happens when I call try Jay(parsing: parsing).jsonFromData(serialized) where serialized is an array of UInt8 and represents a valid JSON object. Jay is failing in line 156 of NumberParser.swift:

//look for other number-allowed chars in this context
//although int-section terminating
if intTerm.contains(reader.curr()) {
    //gracefully end this section
    let intString = try digs.string()
    let int = Int(intString)! // FAILING LINE. intString = "9223372036854776000"    
    return int
}

The error is fatal error: unexpectedly found nil while unwrapping an Optional value. The stack trace looks like:

Current stack trace:
0    libswiftCore.dylib                 0x0000000100f03580 swift_reportError + 132
1    libswiftCore.dylib                 0x0000000100f20850 _swift_stdlib_reportFatalError + 61
2    libswiftCore.dylib                 0x0000000100d1c550 specialized specialized StaticString.withUTF8Buffer<A> ((UnsafeBufferPointer<UInt8>) -> A) -> A + 355
3    libswiftCore.dylib                 0x0000000100e94600 partial apply for (_fatalErrorMessage(StaticString, StaticString, StaticString, UInt, flags : UInt32) -> Never).(closure #2) + 109
4    libswiftCore.dylib                 0x0000000100d1c550 specialized specialized StaticString.withUTF8Buffer<A> ((UnsafeBufferPointer<UInt8>) -> A) -> A + 355
5    libswiftCore.dylib                 0x0000000100e4f970 specialized _fatalErrorMessage(StaticString, StaticString, StaticString, UInt, flags : UInt32) -> Never + 96
6    Jay                                0x000000010081b170 NumberParser.parseInt<A where ...> (A) throws -> Int + 2140
7    Jay                                0x0000000100819f10 NumberParser.parse<A where ...> (with : A) throws -> JSON + 898
8    Jay                                0x0000000100827030 ValueParser.parse<A where ...> (with : A) throws -> JSON + 1653
9    Jay                                0x000000010081d270 ObjectParser.parse<A where ...> (with : A) throws -> JSON + 2269
10   Jay                                0x0000000100827030 ValueParser.parse<A where ...> (with : A) throws -> JSON + 587
11   Jay                                0x000000010081d270 ObjectParser.parse<A where ...> (with : A) throws -> JSON + 2269
12   Jay                                0x0000000100827030 ValueParser.parse<A where ...> (with : A) throws -> JSON + 587
13   Jay                                0x000000010081d270 ObjectParser.parse<A where ...> (with : A) throws -> JSON + 2269
14   Jay                                0x0000000100827030 ValueParser.parse<A where ...> (with : A) throws -> JSON + 587
15   Jay                                0x000000010081d270 ObjectParser.parse<A where ...> (with : A) throws -> JSON + 2269
16   Jay                                0x0000000100827030 ValueParser.parse<A where ...> (with : A) throws -> JSON + 587
17   Jay                                0x00000001007fdf10 ArrayParser.parse<A where ...> (with : A) throws -> JSON + 766
18   Jay                                0x0000000100827030 ValueParser.parse<A where ...> (with : A) throws -> JSON + 1112
19   Jay                                0x000000010081d270 ObjectParser.parse<A where ...> (with : A) throws -> JSON + 2269
20   Jay                                0x0000000100822be0 RootParser.parse<A where ...> (with : A) throws -> JSON + 362
21   Jay                                0x0000000100820920 Parser.parseJsonFromReader<A where ...> (A) throws -> JSON + 132
22   Jay                                0x0000000100820d80 Parser.parseJsonFromData([UInt8]) throws -> JSON + 118
23   Jay                                0x0000000100811950 Jay.jsonFromData([UInt8]) throws -> JSON + 95

I'm using Jay version 1.0.0.

When I run the following code:

let value = ["foo": 42]
print(value)
if let data = try? Jay().dataFromJson(any: value) {
print(String(bytes: data, encoding: String.Encoding.utf8))
}

it outputs

["foo": 42]
Optional("{\"foo\":true}")

Is it expected that Jay interprets the number as a boolean?

The public surface area is pretty small, but it's not well documented, would be nice to make its use as seamless as possible

Consider the following JSON with three double values: [0.608, 0.0608, 0.00608]. When parsed with Jay, the resulting array contains 0.608 three times, so the scale is completely lost.

In other words:

import Jay

let testData = Array("[0.608, 0.0608, 0.00608]".utf8)

let jay = Jay()
let json = try jay.anyJsonFromData(testData)
print(json) // [0.60799999999999998, 0.60799999999999998, 0.60799999999999998]

After some investigation, the culprit is NumberParser.swift:202, where the collected fractional digits are naively converted to an integer. For example when parsing the third number, the digs array ["0", "0", "6", "0", "8"] becomes 608, losing the two initial zeroes.

I'd be cool to also add Cocoapods support. I done this implementation myself last month for my library. Just follow this post and this checklist.

• minimized (default)
• pretty print
• anything else?

With #53 and #59 closed, could you tag a new point release so SPM can pick up the fixes, or is there anything else you consider to be blocking it?

I'm curious how parsing performance compares to other JSON parsers like

• NSJSONSerialization
• yajl
• jsonsl

It would be nice to see some timing results on realistic JSON documents.

Am I correct that the only JSON serialization format supported right now is raw data? I'm guessing this is because this is what JSONSerialization offers?

In practice, I find it annoying to have to work with raw data, as I always work with Strings when using JSON, and let later stages care about which encoding to put it on the wire. As far as I understand, this means I have to always run this through String:validatingUTF8 (and know that the raw data Jay returns is UTF-8, which is undocumented at the moment), and force-unpack the optional (which I can be 100% sure is valid utf-8 anyway); vice versa, it means I have to call .utf8 every time I want to parse something with Jay (which is slightly less annoying than the former).

Wouldn't it be good to offer an API that parses and serializes to Strings?

Also, the fact that the API only takes raw bytes means you have to document which encoding it is in and which encoding it outputs. JSONSerialization takes any encoding, Jay only seems to take UTF-8, (see #54 ).

Currently we don't escape all characters in the 0x00 to 0x1F range, as the spec describes:

All Unicode characters may be placed within the
quotation marks except for the characters that must be escaped:
quotation mark, reverse solidus, and the control characters (U+0000
through U+001F).

We should escape them all, to properly conform.

It seems that the Jay struct should have static functions instead of member functions, since the member functions only create instances of NativeParser and NativeTypeConverter.