Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-10237] Codable: Unexpected behavior supplying default value for nullable field #52637

Open
swift-ci opened this issue Mar 30, 2019 · 2 comments
Open

[SR-10237] Codable: Unexpected behavior supplying default value for nullable field #52637

swift-ci opened this issue Mar 30, 2019 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. Codable Area → standard library: `Codable` and co. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-10237
Radar rdar://problem/33758682
Original Reporter joey (JIRA User)
Type Bug
Environment

Swift 5

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Codable
Assignee None
Priority Medium

md5: e4633977df6db435fe2813d574985f12

Issue Description:

Given a JSON object with a nullable field, such as

{
  "count": null //may be string or null
}

If you try to decode it into this struct

struct Sample: Decodable {
  var count: String = "0" //let's default to 0 if null
}

You'll get the error

valueNotFound(Swift.String, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "count", intValue: nil)], debugDescription: "Expected String value but found null instead.", underlyingError: nil))

I expected no error, and count would be the value if non-null, otherwise "0".

I actually first tried defining count as a let, which worked without error, but this introduced a bug because it will always be that "default" value even when count is non-null.
@belkadan
Copy link
Contributor

belkadan commented Apr 1, 2019

I'm afraid that's just not the behavior of the default init(coder:), and it would be a breaking change to make it so. cc bendjones (JIRA User), @itaiferber

@itaiferber
Copy link
Contributor

Indeed, this was discussed waaaaaayyy back when in https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/037977.html, and although the behavior is surprising to some, the opposite behavior would be equally surprising to others.

We can't read into the intent of why default values are supplied. Sometimes, you'd really want the default value to be used in case decoding fails, but sometimes, you just define a default value to give your type a synthesized init without even considering what that might do for Codable synthesis. There's no way for us to guess correctly, so we do the conservative thing of always trying to decode and not squashing the error silently.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. Codable Area → standard library: `Codable` and co. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@itaiferber @belkadan @swift-ci