Open swift-ci opened 6 years ago
@itaiferber?
I think we just need to have JSONEncoder.decode<T : Decodable>(_ type: T.Type)
not expectNonNull
as it does today. If the value contained is indeed null
, the actual decoding of the inner value will fail for non-optional types.
What we do need to do is handle unboxing the type afterwards correctly. Since the return result here is T
(in which T
may be optional), we might need to differentiate between the result being nil
because it failed, and the result being nil
because nil
is valid.
@swift-ci Create
Environment
Xcode 9.3 Swift 4.1Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 3 | |Component/s | Foundation | |Labels | Bug, Codable | |Assignee | None | |Priority | Medium | md5: d0185b472c3142092e89fd809ebaa821Issue Description:
JSONEncoder can encode a nil single value Optional\<String> as JSON "null", but JSONDecoder does is unable to interpret the null correctly.
Consider:
When the nil Optional\<String> value is encoded, it is encoded as a single-value null as expected.
{"test":null}
But when decoding, an error is thrown:
Note that when switching singleValueContainer to unkeyedContainer, there is no similar error, but the encoded json then looks like: {"test":[null]}