Future of Decodable

[Anviking]

• Would it be possible to gracefully migrate our syntax to rely on Swift 4's Codable instead?
• Would there even be a point in doing that? (yes?)

[voidref]

Not sure I understand the question, it might make sense to migrate our implementation to rely on Swift Decodable, but keep our API surface the same for people who like how it works.

I just had an idea, the fact that our project name collides with Swift is clearly not a great situation, and I suspect that the Swift team is unlikely to rename theirs no matter what pressure we apply ... perhaps the project could be renamed?

Something like Deco?

Just a thought that seemed worthwhile to throw out.

[rayray]

Having played around with Swift 4's Codable, I think there's still value in this framework. Swift's implementation is very rigid, and it's hard to handle edge cases without writing your own decode(), which defeats the purpose.

What's holding up a project rename? Is there anything us outsiders can do to get that started?

[Anviking]

I'm open to renaming, but I think unification with Codable should be explored first. Import boilerplate might be ugly and confusing, but Deco.Decodable and Swift.Decodable just being different, seems to me like a problem that is deeper.

I've played around with implementing this:

public init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: UnsafeKey.self)
        try name = container => "name"
}

// or
public init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        try name = container => .name
}

But I think the devil is in the details, and not yet sure if the rest of the Decodable functionality translate well.

Also

[...] and I suspect that the Swift team is unlikely to rename theirs no matter what pressure we apply [...]

Obviously not – but maybe resolving the collisions usingDecodable.Decodable could be supported.

[robinkunde]

+1 on renaming I also think there's value on this framework doing it's own thing. For one, it's faster, which is useful for situation where you have to decode large json files (I'm thinking of the Slack API here). The other is that allows you to stay more flexible on the implementation side. Using Swift.Decodable internally might hinder adding certain features in the future (hard to say, obviously). Although, I have to say adding the ability to have a decoding context like Swift.Decodable does but be very useful. But that can also be implemented independently.

[Anviking]

+1 on the performance point, I assumed Swift.Decodable was fast before that.

In that case I would propose to release a new version in time for Swift 4.1 with something like the following:

• New name
• Conditional conformances (no code generation)
• Re-evaluated implementation (maybe some big problem can be solved)
  • Should be possible to removeDynamicDecodable now
• (Perhaps) Better error messages (In the same spirit as #124)

Although, I have to say adding the ability to have a decoding context like Swift.Decodable does but be very useful. But that can also be implemented independently.

If you mean the decode-function taking a Decoder instead of json, my current impression is too that it's the way to go.