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.
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.
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.
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
CodingUserInfoKey. which i have no objection to whatsoever.
The proposed changes are in the "Detailed design" section.
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.
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?
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.
Codable.swift is a large file, with only occasional changes.
|Swift 4.1||added conditional conformances.|
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.