RFC swift-json: API spellings for primitive typecasters

Server Development
1

Hi, all, as part of its planned 0.3.0 release, swift-json will be including a new, more-streamlined decoding API for when the compiler-generated Decodable implementation is unsuitable, or does not offer enough control with respect to handling of null entries.

currently we have (these are all methods on JSON.JSON)

// i. non-optional spelling; reports mismatch with `nil`
//
@inlinable public 
func `as`(_:Bool.Type) -> Bool?

// matches `true` and `false` *only*, returns `nil` for 
// all other variant cases.
let _:Bool? = json.as(Bool.self)

// ii. non-optional spelling; throwing, reports mismatch with `Error`
//
@inlinable public 
func `as`(_:Bool.Type) throws -> Bool

// matches `true` and `false` *only*, throws an error for
// all other variant cases.
let _:Bool = try json.as(Bool.self)

// iii. optional spelling; throwing, reports mismatch with `Error`, 
//     reports `null` with `nil`.
//
@inlinable public 
func `as`(_:Bool?.Type) throws -> Bool?

// matches `true`, `false`, and `null`; throws an error for
// all other variant cases.
let _:Bool? = try json.as(Bool?.self)

but before committing to any particular spelling, i was wondering if anyone had any feedback they would like to share.

2

My personal taste would prefer variant ii. I try to avoid optionals as much as I can. Using throw is so much nicer, in particular due to the bubbling up in deeply nested call stacks.

1 Like
3

ah. swift-json will ship with all three APIs, rather i was asking if anything about each specific API variant should be changed. however, i was considering adding a fourth API variant that would return a nested optional:

@inlinable public 
func `as`(_:Bool?.Type) -> Bool??

// matches `true`, `false`, and `null`; returns `nil` in the outer
// optional for all other variant cases.
let _:Bool?? = json.as(Bool?.self)

but it sounds like the utility of this might be limited