Simplify internals of Codable-related APIs

Evolution Pitches
1

This proposal aims to simplify the internals of some Codable-related APIs, by adding two primary associated types and a non-failable initializer to the standard library.

11 Likes
2

Could somebody explain to me what the intended benefit is? Smaller executables? More easily optimized code? Smaller memory footprint?

Would love to learn more about this.

1 Like
3

The primary associated types will only be used internally, but they must still go through the Swift Evolution process. They were also pitched in a previous proposal, but unfortunately I'm responsible for dissuading the author.

The motivation here is to remove four internal classes (one thousand lines of boilerplate code) from the standard library. I don't know if there are any advantages (or disadvantages) to clients of the public APIs.

3 Likes
4

i’m having a hard time understanding what there is to review here, based on a quick reading of the proposal the only externally-observable change is adding an init(_:) to CodingUserInfoKey. which i have no objection to whatsoever.

5

The proposed changes are in the "Detailed design" section.

6

yes, what i meant is that evolution review is supposed to cover changes that affect users of swift. that’s just my long-winded way of saying i don’t think this needs LGTM, but since you asked, it LGTM.

4 Likes
7

Thanks, and I didn’t mean to criticize, I’m just genuinely trying to understand what the goal is — what are the benefits (to folks like you?) of removing the boilerplate code? Maintainability?

8

All standard library changes are subject to Swift Evolution; that doesn't mean it has to be a long review though. I'd agree the changes seem sensible.

5 Likes
9

Codable.swift is a large file, with only occasional changes.

Version History
Swift 4.0 introduced Codable, etc.
Swift 4.1 added conditional conformances.
Swift 5.3 added Float16; reduced generics.
Swift 5.5 added Sendable conformances.
Swift 5.6 added CodingKeyRepresentable.
Swift 5.9 added any keyword, etc.

When auditing those changes, a smaller file is better. According to GitHub, Codable.swift has:

  • 6261 lines (5597 loc) — on the main branch.
  • 5213 lines (4712 loc) — after internal classes are removed.
  • 4574 lines (4072 loc) — after internal classes and inherited documentation comments are removed.
2 Likes