[stdlib] Prevent coercion from Bool to numerical types when decoding JSON and plist

[cpwhidden]

JSONEncoder and PropertyListEncoder both use NSNumber to box Bool values. An encoded Bool can be coerced to any numerical type during decoding because (false as NSNumber).intValue == 0. As a remedy, all of the unbox(_:as:) methods of _JSONDecoder and _PlistDecoder for numerical types include a check that the value is not identical to either kCFBooleanTrue or kCFBooleanFalse, and throw a DecodingError._typeMismatch(at:expectation:) if this check fails.

Right now, Swift can dangerously decode Bool data as a numeric type as in the following examples:

let arrayData = try! JSONEncoder().encode([false, true])
try! JSONDecoder().decode([Int].self, from: arrayData) // == [0,1]

let dictData = try! PropertyListEncoder().encode(["foo":false])
try! PropertyListDecoder().decode([String:Double].self, from: dictData) // == ["foo": 0.0]

struct Foo: Codable {
    let bar: Int
}
try! JSONDecoder().decode(Foo.self, from: JSONEncoder().encode(["bar":true])) // == Foo(bar: 1)

This issue has the potential to affect the correctness of many programs, and in particular programs that depend on the decoding system to validate the application-specific correctness of JSON. It could also be more troublesome for programs when unkeyed containers are used.

Note that currently the opposite is not an issue. Encoded numerical types cannot decode to Bool.

[CodaFi]

(Drive-by CI pass, don't mind me)

@swift-ci please test

[itaiferber]

This looks good to me — this might have backwards-compatibility ramifications, but I think the correctness of this fix is more important. I don't think we ever wanted it to be possible to decode true or false as numeric types. Thanks for putting this together!