Note: This is not the same as #253. However, the issue @tjprescott referenced in #253 is actually this.
When decoding a document like this:
stringA: "Hello"
stringB: ""
into a struct with optional string members like this:
struct TestType: Codable {
var stringA: String?
var stringB: String?
var stringC: String?
}
stringB is read as nil rather than an empty string. If TestType.stringB is made non-optional, it’s read as an empty string.
On further inspection, this could also happen for string values of "~", "null", "Null" or "NULL". This is surprising and dangerous behaviour.
The YAML spec explicitly states: “Note that a null is different from an empty string.” While the style of the spec is confusing, I don’t believe it intends for the string "null" to be of null type either.
This can be fixed by changing NSNull.construct to return nil unless scalar.style == .plain. However, I’m leery of making a PR with this change since it may impact existing code with unfortunate dependencies on the current behaviour.
Note: This is not the same as #253. However, the issue @tjprescott referenced in #253 is actually this.
When decoding a document like this:
into a struct with optional string members like this:
stringBis read as nil rather than an empty string. IfTestType.stringBis made non-optional, it’s read as an empty string.On further inspection, this could also happen for string values of
"~","null","Null"or"NULL". This is surprising and dangerous behaviour.The YAML spec explicitly states: “Note that a null is different from an empty string.” While the style of the spec is confusing, I don’t believe it intends for the string
"null"to be of null type either.This can be fixed by changing
NSNull.constructto return nil unlessscalar.style == .plain. However, I’m leery of making a PR with this change since it may impact existing code with unfortunate dependencies on the current behaviour.