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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
