This might be too late, but anyway:
What is your evaluation of the proposal?
Unsure. For archival purposes/NSCoding replacement this seems great. As the best way to do decode JSON from external APIs I find it at least to be very unconvincing. But then, I’m not sure if this is a goal of the proposal.
Is the problem being addressed significant enough to warrant a change to Swift?
I don’t know.
Does this proposal fit well with the feel and direction of Swift?
To me the proposed implementation doesn’t seem particularly elegant or Swifty.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
(Assuming decoding JSON from external APIs is a goal)
From creating and maintaining the Decodable <https://github.com/Anviking/Decodable> library I learned:
- There are lots of weird APIs out there, that ultimately should be simple to support (e.g how optional values are described, bools as strings, 1-length arrays represented without the wrapping array, etc, etc). This proposal doesn’t talk about these kinds of problems (I don’t even see an optional property in an example), and I haven’t been able to get a sense of whether they are solvable or not with the proposed implementation, which I do not fully understand.
- Good error messages (with like backtraces) are important when writing lots of of decoding code by hand. I see no mentions of error messages in these proposals. Swift-Error breakpoints, could be a solution, but from my experience it’s not really feasible.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Several quick readings and quite a bit of thinking. I am really confused by these proposals though.
Johannes Lund